RE: ecc-subpubkeyinfo draft question: fate of MD-2 and MD-5

[Russ Housley <[e-mail]>]

There was a long discussion a few years ago, and the PKIX WG decided 
that the various applications that make use of certificate should 
select the mandatory to implement algorithms.  In this way, the 
algorithms in the protocol and in the certificates can be aligned.

Russ

At 03:17 PM 9/30/2008, Jim Schaad wrote:
>Alfred,
>
>That is an interesting question.  I don't believe that there have ever been
>any required algorithms for PKIX certificates as defined by the PKIX working
>group.  You have documents such as the S/MIME certificates draft which says
>you need to use these algorithms for S/MIME type certificates instead.
>
>I think that it would make sense to put a section into the security
>considerations that make statements about what we consider to be the
>suitability of other groups adopting these algorithms.   I don't however
>believe we can actually call these algorithms depreciated however.
>
>Jim
>
>
> > -----Original Message-----
> > From: [e-mail] [mailto:owner-ietf-
> > [e-mail]] On Behalf Of Alfred HÎnes
> > Sent: Sunday, September 28, 2008 7:08 PM
> > To: [e-mail]
> > Subject: ecc-subpubkeyinfo draft question: fate of MD-2 and MD-5
> >
> >
> > Folks,
> > the current version of draft-ietf-pkix-ecc-subpubkeyinfo contains
> > unqualified ASN.1 definitions for the digest algorithms MD-2 and MD-5,
> > as well as for  RSA with MD-2 and MD-5.
> >
> > Other WGs already have deprecated MD-2 and/or MD-5 and/or are in the
> > process of deprecating these older hash functions (generally believed
> > to be insecure today), for use in the protocols they maintain.
> >
> > So the question arises what to do with these old algorithms in the
> > context of PKIX in general, and in particular in the above draft.
> >
> > I see four possible options:
> >
> >   A)  leave the draft unchanged
> >
> >   B)  leave the related ASN.1 definitions intact,
> >       but add ASN.1 comments  ' -- DEPRECATED'
> >
> >   C)  keep the related ASN.1 definitions in the document
> >       for the purpose of documentation and historical record,
> >       but comment them out and add the above note
> >
> >   D)  remove he related ASN.1 from the new/upated ASN.1
> >       modules in Appendix A.2 and Appendix A.4 of the draft
> >
> > This question should be decided upon (almost independently):
> >
> >     (1)  for  MD-2  and  RSA with MD-2  ... choices (1A), ... (1D)
> > and
> >     (2)  for  MD-5  and  RSA with MD-5  ... choices (2A), ... (2D)
> >
> > Any opinions?
> >
> > Please indicate support for
> > - one of:            (1A) / (1B) / (1C) / (1D)
> > - and one of:        (2A) / (2B) / (2C) / (2D)
> >
> >
> > Kind regards,
> >   Alfred.
> >
> >
> > P.S.:  My personal preference is  (1C) + (2B) .
> > --
> >
> > +------------------------+--------------------------------------------+
> > | TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
> > | Gerlinger Strasse 12   |  Phone: [phone], Fax: -18         |
> > | D-71254  Ditzingen     |  E-Mail:  [e-mail]                     |
> > +------------------------+--------------------------------------------+
>
>




Received: from 198.156-62-69.ftth.swbr.surewest.net (198.156-62-69.ftth.swbr.surewest.net [69.62.156.198]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m911KS7m034098 for <[e-mail]>; Tue, 30 Sep 2008 18:20:31 -0700 (MST) (envelope-from [e-mail])
From: Nhieu <[e-mail]>
To: <[e-mail]>
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C92329.383F8CD0"
Subject: Enjoy the night life that you wish.
Date: Tue, 30 Sep 2008 18:20:30 -0700
Message-ID: <000701c92363$e49e64d0$c69c3e45@YOUR9A93EB8241>
X-MS-TNEF-Correlator:
Thread-Topic: Enjoy the night life that you wish.
Thread-Index: AckjKTg/q+S7QHbETs2cevlvc1XTVQ==

------=_NextPart_000_0008_01C92329.383F8CD0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

This message was sent to [e-mail]
Unsubscribe | Manage Subscriptions | Privacy Policy
To stop ALL email from CPA Newsletters, click here to remove yourself =
from our lists.
This email was sent by: CPA, 524 W. 57th St., Room 514/1, New York, NY, =
10019
2008 CPA
------=_NextPart_000_0008_01C92329.383F8CD0
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 10 (filtered)">
<title></title>

<style>
<!--
 /* 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:#003366;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {color:#003366;
        text-decoration:underline;}
span.EmailStyle17
        {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;}
-->
</style>

</head>

<body bgcolor=3D"#D3D3DC" lang=3DEN-US link=3D"#003366" vlink=3D"#003366"
alink=3D"#003366">
<DIV align=3Dcenter> <a href=3D"http://www.throughvalue.com"=20
target=3D"_blank"></DIV><BR><DIV><img =
src=3D"http://www.throughvalue.com/main.jpg"=20
border=3D0 alt=3D""></a></DIV><BR><DIV><FONT face=3DArial size=3D2>This =
message was sent=20
to [e-mail]</FONT></DIV><BR><DIV><a=20
href=3D"http://www.throughvalue.com/unsubscribe.asp?email=3Dietf-pkix-arc=
[e-mail]&confirmation=3D8d374367f1de02df6">Unsubscribe</a>=20
| <a=20
href=3D"http://www.throughvalue.com/manage.asp?email=3Dietf-pkix-archive@=
imc.org&confirmation=3D82f52d58421c7f257">Manage=20
Subscriptions | <a=20
href=3D"http://www.throughvalue.com/privacy.asp?email=3Dietf-pkix-archive=
@imc.org&confirmation=3Dc521907ea35f5e3b8">Privacy=20
Policy</a></DIV><BR><DIV>To stop ALL email from CPA Newsletters, click =
<a=20
href=3D"http://www.throughvalue.com/unsubscribe.asp?email=3Dietf-pkix-arc=
[e-mail]&confirmation=3D2ad8d1c8db8c97">here</a>=20
to remove yourself from our lists.</DIV><BR><DIV><FONT face=3DArial =
size=3D2>This=20
email was sent by: CPA, 524 W. 57th St., Room 514/1, New York, NY,=20
10019</FONT></DIV><BR><DIV><FONT face=3DArial size=3D2>2008 =
CPA</FONT></DIV>
</body>

</html>

------=_NextPart_000_0008_01C92329.383F8CD0--


Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m8ULSUpx021112 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Sep 2008 14:28:30 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8ULSUtb021111; Tue, 30 Sep 2008 14:28:30 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [8.8.40.152]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m8ULSJcx021101 for <[e-mail]>; Tue, 30 Sep 2008 14:28:29 -0700 (MST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
Received: (qmail 10289 invoked by uid 0); 30 Sep 2008 21:23:08 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (96.255.145.18) by woodstock.binhost.com with SMTP; 30 Sep 2008 21:23:08 -0000
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Tue, 30 Sep 2008 17:22:37 -0400
To: "Jim Schaad" <[e-mail]>, "'Alfred HÎnes'" <[e-mail]>, <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: RE: ecc-subpubkeyinfo draft question: fate of MD-2 and MD-5
In-Reply-To: <001301c92331$3ab9baf0$b02d30d0$@com>
References: <[e-mail]> <001301c92331$3ab9baf0$b02d30d0$@com>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

There was a long discussion a few years ago, and the PKIX WG decided 
that the various applications that make use of certificate should 
select the mandatory to implement algorithms.  In this way, the 
algorithms in the protocol and in the certificates can be aligned.

Russ

At 03:17 PM 9/30/2008, Jim Schaad wrote:
>Alfred,
>
>That is an interesting question.  I don't believe that there have ever been
>any required algorithms for PKIX certificates as defined by the PKIX working
>group.  You have documents such as the S/MIME certificates draft which says
>you need to use these algorithms for S/MIME type certificates instead.
>
>I think that it would make sense to put a section into the security
>considerations that make statements about what we consider to be the
>suitability of other groups adopting these algorithms.   I don't however
>believe we can actually call these algorithms depreciated however.
>
>Jim
>
>
> > -----Original Message-----
> > From: [e-mail] [mailto:owner-ietf-
> > [e-mail]] On Behalf Of Alfred HÎnes
> > Sent: Sunday, September 28, 2008 7:08 PM
> > To: [e-mail]
> > Subject: ecc-subpubkeyinfo draft question: fate of MD-2 and MD-5
> >
> >
> > Folks,
> > the current version of draft-ietf-pkix-ecc-subpubkeyinfo contains
> > unqualified ASN.1 definitions for the digest algorithms MD-2 and MD-5,
> > as well as for  RSA with MD-2 and MD-5.
> >
> > Other WGs already have deprecated MD-2 and/or MD-5 and/or are in the
> > process of deprecating these older hash functions (generally believed
> > to be insecure today), for use in the protocols they maintain.
> >
> > So the question arises what to do with these old algorithms in the
> > context of PKIX in general, and in particular in the above draft.
> >
> > I see four possible options:
> >
> >   A)  leave the draft unchanged
> >
> >   B)  leave the related ASN.1 definitions intact,
> >       but add ASN.1 comments  ' -- DEPRECATED'
> >
> >   C)  keep the related ASN.1 definitions in the document
> >       for the purpose of documentation and historical record,
> >       but comment them out and add the above note
> >
> >   D)  remove he related ASN.1 from the new/upated ASN.1
> >       modules in Appendix A.2 and Appendix A.4 of the draft
> >
> > This question should be decided upon (almost independently):
> >
> >     (1)  for  MD-2  and  RSA with MD-2  ... choices (1A), ... (1D)
> > and
> >     (2)  for  MD-5  and  RSA with MD-5  ... choices (2A), ... (2D)
> >
> > Any opinions?
> >
> > Please indicate support for
> > - one of:            (1A) / (1B) / (1C) / (1D)
> > - and one of:        (2A) / (2B) / (2C) / (2D)
> >
> >
> > Kind regards,
> >   Alfred.
> >
> >
> > P.S.:  My personal preference is  (1C) + (2B) .
> > --
> >
> > +------------------------+--------------------------------------------+
> > | TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
> > | Gerlinger Strasse 12   |  Phone: [phone], Fax: -18         |
> > | D-71254  Ditzingen     |  E-Mail:  [e-mail]                     |
> > +------------------------+--------------------------------------------+
>
>



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m8UJI4aJ011686 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Sep 2008 12:18:04 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8UJI4ER011685; Tue, 30 Sep 2008 12:18:04 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m8UJHr7q011662 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <[e-mail]>; Tue, 30 Sep 2008 12:18:04 -0700 (MST) (envelope-from [e-mail])
Received: from GALATIONS (67-150-21-210.lsan.mdsg-pacwest.com [67.150.21.210]) by smtp2.pacifier.net (Postfix) with ESMTP id E5EC46B485; Tue, 30 Sep 2008 12:17:46 -0700 (PDT)
From: "Jim Schaad" <[e-mail]>
To: "=?iso-8859-1?Q?'Alfred_H=CEnes'?=" <[e-mail]>, <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Subject: RE: ecc-subpubkeyinfo draft question: fate of MD-2 and MD-5
Date: Tue, 30 Sep 2008 12:17:39 -0700
Message-ID: <001301c92331$3ab9baf0$b02d30d0$@com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPart_000_0014_01C922F6.8E5AE2F0"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ackh2h4y4Fq4tcYfTR+7oWJNIbpIeAAynDaQ
Content-Language: en-us
X-MS-TNEF-Correlator: 00000000C61F957EEEE3D311963C000086335A64049EA600
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multipart message in MIME format.

------=_NextPart_000_0014_01C922F6.8E5AE2F0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Alfred,

That is an interesting question.  I don't believe that there have ever =
been
any required algorithms for PKIX certificates as defined by the PKIX =
working
group.  You have documents such as the S/MIME certificates draft which =
says
you need to use these algorithms for S/MIME type certificates instead.

I think that it would make sense to put a section into the security
considerations that make statements about what we consider to be the
suitability of other groups adopting these algorithms.   I don't however
believe we can actually call these algorithms depreciated however.

Jim


> -----Original Message-----
> From: [e-mail] [mailto:owner-ietf-
> [e-mail]] On Behalf Of Alfred H=CEnes
> Sent: Sunday, September 28, 2008 7:08 PM
> To: [e-mail]
> Subject: ecc-subpubkeyinfo draft question: fate of MD-2 and MD-5
>=20
>=20
> Folks,
> the current version of draft-ietf-pkix-ecc-subpubkeyinfo contains
> unqualified ASN.1 definitions for the digest algorithms MD-2 and MD-5,
> as well as for  RSA with MD-2 and MD-5.
>=20
> Other WGs already have deprecated MD-2 and/or MD-5 and/or are in the
> process of deprecating these older hash functions (generally believed
> to be insecure today), for use in the protocols they maintain.
>=20
> So the question arises what to do with these old algorithms in the
> context of PKIX in general, and in particular in the above draft.
>=20
> I see four possible options:
>=20
>   A)  leave the draft unchanged
>=20
>   B)  leave the related ASN.1 definitions intact,
>       but add ASN.1 comments  ' -- DEPRECATED'
>=20
>   C)  keep the related ASN.1 definitions in the document
>       for the purpose of documentation and historical record,
>       but comment them out and add the above note
>=20
>   D)  remove he related ASN.1 from the new/upated ASN.1
>       modules in Appendix A.2 and Appendix A.4 of the draft
>=20
> This question should be decided upon (almost independently):
>=20
>     (1)  for  MD-2  and  RSA with MD-2  ... choices (1A), ... (1D)
> and
>     (2)  for  MD-5  and  RSA with MD-5  ... choices (2A), ... (2D)
>=20
> Any opinions?
>=20
> Please indicate support for
> - one of:            (1A) / (1B) / (1C) / (1D)
> - and one of:        (2A) / (2B) / (2C) / (2D)
>=20
>=20
> Kind regards,
>   Alfred.
>=20
>=20
> P.S.:  My personal preference is  (1C) + (2B) .
> --
>=20
> =
+------------------------+--------------------------------------------+
> | TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  =
|
> | Gerlinger Strasse 12   |  Phone: [phone], Fax: -18         =
|
> | D-71254  Ditzingen     |  E-Mail:  [e-mail]                     =
|
> =
+------------------------+--------------------------------------------+


------=_NextPart_000_0014_01C922F6.8E5AE2F0
Content-Type: application/ms-tnef;
	name="winmail.dat"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="winmail.dat"

eJ8+IjITAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy
b3NvZnQgTWFpbC5Ob3RlADEIAQYABwABAAAAAAAAAQOQBgDkDAAANgAAAAsAAgABAAAAAwAmAAAA
AAALACkAAAAAAAsAKwAAAAAAAwAuAAAAAAACATEAAQAAABgAAAAAAAAAxh+Vfu7j0xGWPAAAhjNa
ZESdpgAeAHAAAQAAADgAAABlY2Mtc3VicHVia2V5aW5mbyBkcmFmdCBxdWVzdGlvbjogZmF0ZSBv
ZiBNRC0yIGFuZCBNRC01AAIBcQABAAAAGwAAAAHJIdoeMuBauLXGH00fu6FiTSG6SHgAMpw2kAAL
AAEOAAAAAAIBCg4BAAAAGAAAAAAAAADGH5V+7uPTEZY8AACGM1pkwoAAAAMAFA4BAAAAHgAoDgEA
AAA3AAAAMDAwMDAwMGIBaWV0ZkBhdWd1c3RjZWxsYXJzLmNvbQFpZXRmQGF1Z3VzdGNlbGxhcnMu
Y29tAAAeACkOAQAAADcAAAAwMDAwMDAwYgFpZXRmQGF1Z3VzdGNlbGxhcnMuY29tAWlldGZAYXVn
dXN0Y2VsbGFycy5jb20AAAIBCRABAAAA7wYAAOsGAAANDQAATFpGdcTEB04DAAoAcmNwZzEyNSIy
A0N0ZXgFQmJp/mQEAAMwAQMB9wqAAqQD4wkCAGNoCsBzZXQw/iAHEwKAEHMAUARWCFUHsu8SRQ5R
AwERRzIGAAbDEkV+MwRGEUkTWxJTCO8J9zvbGT8OMDUSQgxgYwBQCwm5AWQzNhHQC6YR4GwDUN0J
gCwKogqECoBUEXAFQJ8PUQORC4AOsBlAc3QLgDhnIHEKUCBRAiAuIFAgSSBkAiAnBUBihGVsCJB2
ZSB0H1L7ImAgISARcCIxIiEFwCHgswnwH7F5IBlAILBpGUGpH7BsZwWwaSJgbQQgAwIQBcBQS0lY
IGO7BJAgYGYN4B9gB5FhBCB3AQELgCShYiQgIrEltHddBbBrIHIJwAhgcCExWecIYCMEIYBjdQeA
AjAEIBpzG/BoJtInwlMvTYhJTUUmDGRyYQGAjShAaA3gKrBzYXkEIA55KWEnUCShdG8gdR8RoCKi
LmEk3StFdHlwDyJAJhsLgCBQZWFkLu8eiiFgImALgGsiVCUgKEHsdWwksADAayJAEaAAgFMiQS4w
cHUFQGE0UWP/IPIf4i4wJ8I1UQhxMFAmAP8CIACQBIEfYCEBKuIfYTQUfwGQDrAqJAGgCGAswh9h
d/8wgTcFLhIh4DYUJHABkQMQ+Tayb2Y78CKyKMQfoSGAnwUwIHIuniExIVdobzngnyN0IgQ54gOR
ANB0dQdAXmw20UEBPY8nAXAZQGPfBzAOsCSwP1Ux60oHcB6KUR6EPiAtRiJPBRBnnwuAB0AF0AeQ
LUBnZUYjVUWmRgNhOjvwdydQciYtCJAAMC1wKIB4QMsAwAMQLgdwYy4FsCCQdltJoi4gOkipRaZJ
X13kIE8DoEJlEXAeIE1AwzwQHhQgSFwnJhAnUB8RMEW1BmACMEiAU3Vu+mQtUCwGUQUwOMAh4AXA
DDI4UFAB0DA4IDfSOlFxUE1FplRK0B+Ax0kXSfVPF3ViajVhSICpBZBjLSqAYjTwYjQwvnkLgAIQ
LHUgtkiAZiaR8TvyTUQtFWAAcCSwV5GWNUWmWG5GBvBrcx5130YAJ8I2gRlAAjAgI3EAkO81oTwB
LINI+C1U/zbiAZB/MXFFplAAILAHQCZRJKFB8FNOLjEnBCUgN5Mlgv8nwg9AR1AgUCTKV5taNybh
nzngQXEm4SWCB/BTQShALyUhV4wx5VjITzxDV0f9H6FsGUAxwCQgKZRCw0Mj/VeWLwWyWDFqBgrA
IkALgP8iokunA2AmEAQRXAJpJT1Y1wbwOmIRcHMqsGZQADVz/QQgKEdQSMFBAyHlCzFaZd86szFx
NnI0olAhKVBQJYL/LlJrhGxSLiAYsSrjJCBJoftec2afUzYEILZrMQQAB5H/OZMuISGAZWRt1yTK
a4xeUv8OwjwBJcNrgW+VUFBX4muB/wqxIGAqAAtgBcBzJTkxKbL/LJJ1DyFgEaAiQAIQCHA04Hpv
BBBpAmBXQT0xNwE681huIUBBKSFAgNAjImFzvyyTbvERcCCAcJiCCEKCu/8ZQAtgQzJgHx/iQMFa
N4j0WmI1AmSG1gWgbSokIAInRhEgREVQUkXAQ0FURUQnhH8TQP+CsTQwQsCGL4c+YWQp9YiM+2E2
NPBygHFXQynmN3NX0/8s8CBQJQFBUSQxBaEeZojq+4pFIqJtO/A1AlfxiaJ9yO5uPDBr14IIRIKx
GUAEYJ8iMY2vA1InsydQdy8pAL+OCJS8BGEz0DFDEeBwMHC3UBBJcBHgLlfEnkk0O/L/g0dYbh9A
D1F2h26wM8M60d8FgTcxJLApADWhKAdABGC/YfELgEKxnnEqMUEgKYF/+YjyKDGCsWTjV5NX02Ut
/CAuqSAmAD9QDeAHkabg/4KgUFCpIqbgmWBjt1AQpiu+MqcJarCn36zyqSsyqgf2MqqoRaZBJBE9
IGChNwH6P1huUILhcvMPQCaCKnH/nlAY4SVyRac78CdQO/FIgPO1qaniIC+m0YWRtrKNAX+2sqqo
ixBX4rU9rzK2ojLdtvQyt2Sv77u4S6SxJDF+ZwsRWiiCgR4jfr+yZy70Uy61kU0kIDBwEZACIPtG
0ULRZiAhbwBrYYqxt0PeK7okvqdHqEWmK0YjxR9fRiDEz8dfxapFpnxSgFLuLQawBCBOJm9O0j6h
ybBNyj9EBSBJ0C1NH2BoZi5QUMx0UGgtYCExfL3JOEcEkCIAhDEvwXQskH8EECJADiDLFM2gtTFI
gCgAKzQ5KTcxNTaALzk2MzUtMFBQyEZheEiALTFRgLWmP84ZV6DRIA4woADMYXR6788CA6DSwyFA
RczBAxC1kehhaEDJ1C4BALWq0n+/xL/Fz9qP25/I+B6Efd3AAAIBFDoBAAAAEAAAAMA5XqyIZwBH
jehGALSLGIoDAN4/r28AAAMA8T8JBAAAAwAJWQEAAAADAACACCAGAAAAAADAAAAAAAAARgAAAAAQ
hQAAAAAAAAsABYAIIAYAAAAAAMAAAAAAAABGAAAAAAaFAAAAAAAAAwAGgAggBgAAAAAAwAAAAAAA
AEYAAAAAAYUAAAAAAAALAAeACCAGAAAAAADAAAAAAAAARgAAAAADhQAAAAAAAAsACIAIIAYAAAAA
AMAAAAAAAABGAAAAAA6FAAAAAAAAAwAKgAggBgAAAAAAwAAAAAAAAEYAAAAAGIUAAAAAAAALABaA
CCAGAAAAAADAAAAAAAAARgAAAACChQAAAQAAAAsAT4ADIAYAAAAAAMAAAAAAAABGAAAAAByBAAAA
AAAAAwBTgAMgBgAAAAAAwAAAAAAAAEYAAAAAAYEAAAAAAAADAFSAAyAGAAAAAADAAAAAAAAARgAA
AAATgQAAAQAAAAMAVoADIAYAAAAAAMAAAAAAAABGAAAAACOBAAD///9/CwAUgQMgBgAAAAAAwAAA
AAAAAEYAAAAAJoEAAAAAAAALABeBAyAGAAAAAADAAAAAAAAARgAAAAADgQAAAAAAAAUAJIEDIAYA
AAAAAMAAAAAAAABGAAAAAAKBAAAAAAAAAAAAAAMAJYEDIAYAAAAAAMAAAAAAAABGAAAAABCBAAAA
AAAAAwAmgQMgBgAAAAAAwAAAAAAAAEYAAAAAEYEAAAAAAAALACuBAyAGAAAAAADAAAAAAAAARgAA
AAAkgQAAAAAAAAsALIEDIAYAAAAAAMAAAAAAAABGAAAAACyBAAAAAAAAAwAtgQMgBgAAAAAAwAAA
AAAAAEYAAAAAKYEAAAAAAAADAC6BAyAGAAAAAADAAAAAAAAARgAAAAAqgQAAAAAAAB4AM4EDIAYA
AAAAAMAAAAAAAABGAAAAACeBAAABAAAAAQAAAAAAAAADADaBAyAGAAAAAADAAAAAAAAARgAAAAAS
gQAAAQAAAB4AOYEDIAYAAAAAAMAAAAAAAABGAAAAACGBAAABAAAAAQAAAAAAAAALAB8OAQAAAAIB
+A8BAAAAEAAAAMYflX7u49MRljwAAIYzWmQCAfoPAQAAABAAAADGH5V+7uPTEZY8AACGM1pkAwD+
DwUAAAADAA00/T+jBgMADzT9P6MGAgEUNAEAAAAQAAAATklUQfm/uAEAqgA32W4AAAIBfwABAAAA
MQAAADAwMDAwMDAwQzYxRjk1N0VFRUUzRDMxMTk2M0MwMDAwODYzMzVBNjQwNDlFQTYwMAAAAAAD
AAYQcOA3zgMABxDgBwAAAwAQEAAAAAADABEQAAAAAB4ACBABAAAAZQAAAEFMRlJFRCxUSEFUSVNB
TklOVEVSRVNUSU5HUVVFU1RJT05JRE9OVEJFTElFVkVUSEFUVEhFUkVIQVZFRVZFUkJFRU5BTllS
RVFVSVJFREFMR09SSVRITVNGT1JQS0lYQ0VSVEkAAAAA3GU=

------=_NextPart_000_0014_01C922F6.8E5AE2F0--



Received: from [204.248.16.200] ([204.248.16.200]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m8UDdiQG084326 for <[e-mail]>; Tue, 30 Sep 2008 06:39:48 -0700 (MST) (envelope-from Atlas-pel{[e-mail])
From: Atlas <Atlas-pel{[e-mail]>
To: <[e-mail]>
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C922E0.6A76D080"
Subject: Are the nights full of pleasure good for you?
Date: Tue, 30 Sep 2008 09:39:21 -0400
Message-ID: <000401c92301$f1887080$c810f8cc@SaqibPC>
X-MS-TNEF-Correlator:
Thread-Topic: Are the nights full of pleasure good for you?
Thread-Index: Acki4Gp2VQRlKq4XTNmtCvQiNFm9Jw==

------=_NextPart_000_0005_01C922E0.6A76D080
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

This message was sent to [e-mail]
Unsubscribe | Manage Subscriptions | Privacy Policy
To stop ALL email from CPA Newsletters, click here to remove yourself =
from our lists.
This email was sent by: CPA, 524 W. 57th St., Room 514/1, New York, NY, =
10019
2008 CPA
------=_NextPart_000_0005_01C922E0.6A76D080
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 10 (filtered)">
<title></title>

<style>
<!--
 /* 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:#003366;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {color:#003366;
        text-decoration:underline;}
span.EmailStyle17
        {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;}
-->
</style>

</head>

<body bgcolor=3D"#D3D3DC" lang=3DEN-US link=3D"#003366" vlink=3D"#003366"
alink=3D"#003366">
<DIV align=3Dcenter> <a href=3D"http://www.mineneed.com"=20
target=3D"_blank"></DIV><BR><DIV><img =
src=3D"http://www.mineneed.com/header.jpg"=20
border=3D0 alt=3D""></a></DIV><BR><DIV><FONT face=3DArial size=3D2>This =
message was sent=20
to [e-mail]</FONT></DIV><BR><DIV><a=20
href=3D"http://www.mineneed.com/unsubscribe.asp?email=3Dietf-pkix-archive=
@imc.org&confirmation=3D80787a207012f002f">Unsubscribe</a>=20
| <a=20
href=3D"http://www.mineneed.com/manage.asp?email=3Dietf-pkix-archive@imc.=
org&confirmation=3Df2ce092742c3084f7">Manage=20
Subscriptions | <a=20
href=3D"http://www.mineneed.com/privacy.asp?email=3Dietf-pkix-archive@imc=
org&confirmation=3D14368d11faeb007e3">Privacy=20
Policy</a></DIV><BR><DIV>To stop ALL email from CPA Newsletters, click =
<a=20
href=3D"http://www.mineneed.com/unsubscribe.asp?email=3Dietf-pkix-archive=
@imc.org&confirmation=3D304e3f9add9f77">here</a>=20
to remove yourself from our lists.</DIV><BR><DIV><FONT face=3DArial =
size=3D2>This=20
email was sent by: CPA, 524 W. 57th St., Room 514/1, New York, NY,=20
10019</FONT></DIV><BR><DIV><FONT face=3DArial size=3D2>2008 =
CPA</FONT></DIV>
</body>

</html>

------=_NextPart_000_0005_01C922E0.6A76D080--


Received: from MTLXPQAK-1279391871.sdsl.bell.ca (MTLXPQAK-1279391871.sdsl.bell.ca [76.65.248.127]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m8U2m2UU028220 for <[e-mail]>; Mon, 29 Sep 2008 19:48:14 -0700 (MST) (envelope-from [e-mail])
From: Avram <[e-mail]>
To: <[e-mail]>
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_000F_01C92285.761963E0"
Subject: How to buy medzz online
Date: Mon, 29 Sep 2008 22:48:16 -0400
Message-ID: <000e01c922a6$fd2b03e0$7ff8414c@655103PC01>
X-MS-TNEF-Correlator:
Thread-Topic: How to buy medzz online
Thread-Index: AckihXYZ36bvIKmwRUORLSM0g6oTfA==

------=_NextPart_000_000F_01C92285.761963E0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

This message was sent to [e-mail]
Unsubscribe | Manage Subscriptions | Privacy Policy
To stop ALL email from CPA Newsletters, click here to remove yourself =
from our lists.
This email was sent by: CPA, 524 W. 57th St., Room 514/1, New York, NY, =
10019
2008 CPA
------=_NextPart_000_000F_01C92285.761963E0
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 10 (filtered)">
<title></title>

<style>
<!--
 /* 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:#003366;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {color:#003366;
        text-decoration:underline;}
span.EmailStyle17
        {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;}
-->
</style>

</head>

<body bgcolor=3D"#D3D3DC" lang=3DEN-US link=3D"#003366" vlink=3D"#003366"
alink=3D"#003366">
<DIV align=3Dcenter> <a href=3D"http://www.moneyfight.com"=20
target=3D"_blank"></DIV><BR><DIV><img =
src=3D"http://www.moneyfight.com/accept.jpg"=20
border=3D0 alt=3D""></a></DIV><BR><DIV><FONT face=3DArial size=3D2>This =
message was sent=20
to [e-mail]</FONT></DIV><BR><DIV><a=20
href=3D"http://www.moneyfight.com/unsubscribe.asp?email=3Dietf-pkix-archi=
[e-mail]&confirmation=3D0394b68c36f1ddc3b">Unsubscribe</a>=20
| <a=20
href=3D"http://www.moneyfight.com/manage.asp?email=3Dietf-pkix-archive@im=
c.org&confirmation=3D61ad35d1428df228b">Manage=20
Subscriptions | <a=20
href=3D"http://www.moneyfight.com/privacy.asp?email=3Dietf-pkix-archive@i=
mc.org&confirmation=3D3575ea427033cabb7">Privacy=20
Policy</a></DIV><BR><DIV>To stop ALL email from CPA Newsletters, click =
<a=20
href=3D"http://www.moneyfight.com/unsubscribe.asp?email=3Dietf-pkix-archi=
[e-mail]&confirmation=3Ddb6a95f5030308">here</a>=20
to remove yourself from our lists.</DIV><BR><DIV><FONT face=3DArial =
size=3D2>This=20
email was sent by: CPA, 524 W. 57th St., Room 514/1, New York, NY,=20
10019</FONT></DIV><BR><DIV><FONT face=3DArial size=3D2>2008 =
CPA</FONT></DIV>
</body>

</html>

------=_NextPart_000_000F_01C92285.761963E0--


Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m8TIQtdT092145 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 29 Sep 2008 11:26:55 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8TIQtEH092144; Mon, 29 Sep 2008 11:26:55 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m8TIQhoD092128 for <[e-mail]>; Mon, 29 Sep 2008 11:26:54 -0700 (MST) (envelope-from [e-mail])
Received: from Augustine.missi.ncsc.mil (augustine.missi.ncsc.mil [144.51.60.33]) by stingray.missi.ncsc.mil with ESMTP id m8TIQgQj019624; Mon, 29 Sep 2008 14:26:42 -0400 (EDT)
Received: from DABECK.missi.ncsc.mil ([144.51.60.15]) by Augustine.missi.ncsc.mil with Microsoft SMTPSVC(6.0.3790.3959); Mon, 29 Sep 2008 14:25:26 -0400
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: Comments on draft-ietf-pkix-ecc-subpubkeyinfo-08
Date: Mon, 29 Sep 2008 14:26:40 -0400
Message-ID: <[e-mail]>
In-Reply-To: <EABB301176B04E1A9D5CFF8CD28AF11F@Wylie>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Comments on draft-ietf-pkix-ecc-subpubkeyinfo-08
thread-index: AckeW2kLqBp2woPRTKqr8+CgZIX2zQD7IWXwAASivSA=
References: <[e-mail]> <A6CB9F5557F049C9BC950FF3A5C46586@Wylie> <[e-mail]> <EABB301176B04E1A9D5CFF8CD28AF11F@Wylie>
From: "Kemp, David P." <[e-mail]>
To: "Turner, Sean P." <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 29 Sep 2008 18:25:26.0796 (UTC) FILETIME=[BEACA4C0:01C92260]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a significant change in logic, from implicitCurve MUST NOT be
used (because specifiedCurve is no longer an option) to implicitCurve
MAY be used.

Because DSA certificates don't have an equivalent "namedParameters"
construct, the ability to inherit specified parameters enables some
space savings.  But a namedCurve OID isn't very large so the potential
benefits of implicitCurve aren't very large either.  I'd suggest a
strict/liberal requirement, which in the absence of specifiedCurve may
be simplified to:

o implicitCurve allows the elliptic curve parameters to be inherited.
Certificates MUST use the namedCurve option.  Relying-party applications
MAY support the implicitCurve choice in order to accept certificates
that do not use the namedCurve option. =20

Do any implementers who are comfortable with parameter inheritance in
DSA feel that there is any reason to generate ecc certificates using
implicitCurve?
=20
Dave

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Turner, Sean P.
Sent: Monday, September 29, 2008 11:35 AM
To: [e-mail]
Subject: RE: Comments on draft-ietf-pkix-ecc-subpubkeyinfo-08


On implicitCurve, the text was written when specifiedCurve was an
option.
Now that it's gone, I'd suggest a change from:

o implicitCurve allows the elliptic curve parameters to be inherited.
This
choice MAY be supported, but if subordinate certificates use the same
namedCurve as their superior, then the subordinate certificate MUST use
the
namedCurve option. That is, implicitCurve is only supported if the
superior
doesn't use the namedCurve option. =20

To:

o implicitCurve allows the elliptic curve parameters to be inherited.
This
choice MAY be supported.

spt

>-----Original Message-----
>From: [e-mail]=20
>[mailto:[e-mail]] On Behalf Of Russ Housley
>Sent: Wednesday, September 24, 2008 9:06 AM
>To: [e-mail]
>Subject: RE: Comments on draft-ietf-pkix-ecc-subpubkeyinfo-08
>
>
>Two points.
>
>My initial reaction to implicitCurve is that many people that=20
>support DSA already deal with parameter inheritance in that=20
>context.  So, it may not be a burden to keep this capability=20
>in the specification.  Are implementors finding this to be a problem?
>
>It is probably a good idea to avoid the down reference at this=20
>point.  There are several ways to resolve this concern.  One=20
>simple way is to include two ASN.1 modules in the this document.
>
>Russ
>
>At 06:56 PM 9/23/2008, Turner, Sean P. wrote:
>
>>Carl,
>>
>>Thanks for taking the time to review the draft.  Responses in-line.
>>
>>spt
>>
>> >-----Original Message-----
>> >From: [e-mail]
>> >[mailto:[e-mail]] On Behalf Of Carl Wallace
>> >Sent: Tuesday, September 23, 2008 4:07 PM
>> >To: [e-mail]
>> >Subject: Comments on draft-ietf-pkix-ecc-subpubkeyinfo-08
>>
>>snip
>>
>> >- In section 2.1.1, why is implicitCurve not deprecated along with=20
>> >specifiedCurve?  The text states that implicitCurve is only=20
>supported=20
>> >when namedCurve is not used and there is no option other than=20
>> >namedCurve available.
>>
>>It does seem like this choice ought to be deprecated too because it=20
>>says you always use namedCurve.
>>
>> >- Why is A.2 the informative module?  Most sections in the spec=20
>> >reference definitions from A.2.
>>
>>I figured this was a style thing. I like the class definition way of=20
>>defining the keys and curves because I think it's clearer. =20
>BUT, we do=20
>>have this problem of a dependancy on draft-ietf-pkix-new-asn1.  If we=20
>>used the "old" way of defining the structures in the main body of the=20
>>document, I'd recommend blowing away the all of the new ASN.1 and=20
>>putting it in Jim/Paul's
>>draft-ietf-pkix-new-asn1 ID or some other ID to not slow down=20
>completion.
>>
>>ALL: Should we only use the "old" ASN.1 in the document and move all=20
>>the "new" ASN.1 to another document?
>>
>> >- Given the amount of repetition between the ASN.1 modules, it may=20
>> >make more sense to define all of the structures and OIDs once and=20
>> >import them into one module that uses information objects and one=20
>> >that doesn't.  I think ECParameters is the only structure=20
>that would=20
>> >need to go in the module that doesn't use information objects.
>>
>>I made one for curves and one for algorithm IDs, key format, and=20
>>parameter structures.  Then imported the curves, IDs, formats, and=20
>>structures in the information object module and the curves in to the=20
>>ECParameters module. I think it took off 2 pages, but there=20
>ought to be=20
>>less chances of me copying things incorrectly.
>>
>> >- Expand EC in third paragraph of section 1
>> >- "algorithms" should be singular in the first sentence of section=20
>> >2.1
>> >- Provide a reference to 5280 where SubjectPublicKeyInfo is defined=20
>> >in Section 2
>> >- In 2.1.2, change "fall in to different" to "fall in two=20
>different"=20
>> >or "fall into different"
>> >- Rewrite last sentence of section 3 to remove the condition since=20
>> >the certificate MUST assert keyAgreement or make the=20
>statement about=20
>> >asserting encipherOnly or decipherOnly one time instead of once per=20
>> >certificate type.
>> >- In Security Considerations, change "desired have value"=20
>to "desired=20
>> >hash value"
>> >- In second paragraph of section 5, "implementations" should be=20
>> >singular.
>>
>>Fixed
>>
>> >- Where there are references to X9.62, the names of the structures=20
>> >should be the same.  ECParameters and SpecifiedCurve appear as=20
>> >ECDomainParameters and SpecifiedECDomain in X9.62.
>>
>>There's been lots of name changes to these four fields. We point to=20
>>both
>>SEC1 and ANSI X9 and we also have RFC 3279.
>>What we're calling ECParameters:
>>   RFC3279 called them EcpkParameters
>>   SEC1 v1 called them Parameters
>>   ANSI X9.62:2005 called them ECDomainParameters What we're calling=20
>>namedCurve:
>>   RFC3279 called them namedCurve
>>   SEC1 v1 called them namedCurve
>>   ANSI X9.62:2005 called them named
>>What we're calling specifiedCurve:
>>   RFC3279 called them ecParameters
>>   SEC1 called them ecParameters
>>   ANSI X9.62:2005 called them specified What we're calling=20
>>SpecifiedCurve:
>>   RFC3279 called them ECParameters
>>   SEC1 called them ECParameters
>>   ANSI X9.62:2005 called them SpecifiedECDomain What we're calling=20
>>implicitCurve:
>>   RFC3279 called them implicitlyCA
>>   SEC1 called them implicitCA
>>   ANSI X9.62:2005 called them implicitCA
>>
>>Seemed like we could do our own thing here.  ECParameters makes sense=20
>>as a name for the top level because it's the parameters for=20
>the EC.  I=20
>>aligned the names to namedCurve, specifiedCurve, and implicitCurve=20
>>because they're all variations on a theme: OID, full=20
>specification, and=20
>>implied (can come from places other than the CA's cert).  I=20
>changed the=20
>>name of SpecifedCurve to SpecifiedECDomain parameters but=20
>left the other field names as is.
>



Received: from host202-3-static.89-82-b.business.telecomitalia.it (host202-3-static.89-82-b.business.telecomitalia.it [82.89.3.202]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m8TG9R01079617 for <[e-mail]>; Mon, 29 Sep 2008 09:09:30 -0700 (MST) (envelope-from [e-mail])
Received: from [82.89.3.202] (port=46786 helo=host202-3-static.89-82-b.business.telecomitalia.it) by mail.imc.org with esmtp  id 5ab661-8f6e8a-e6 for [e-mail]; Mon, 29 Sep 2008 18:09:21 +0100
Message-ID: <[e-mail]>
Date: Mon, 29 Sep 2008 18:09:21 +0100
From: "Otis" <[e-mail]>
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: "Benito" <[e-mail]>
Subject: power ix
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

natural and effective coctail

never faile and ... lowcost

http://poltkaed.com






Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m8TFZUKL076550 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 29 Sep 2008 08:35:30 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8TFZUIp076549; Mon, 29 Sep 2008 08:35:30 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp105.biz.mail.re2.yahoo.com (smtp105.biz.mail.re2.yahoo.com [206.190.52.174]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m8TFZJK1076532 for <[e-mail]>; Mon, 29 Sep 2008 08:35:29 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 14776 invoked from network); 29 Sep 2008 15:35:18 -0000
Received: from unknown (HELO Wylie) ([e-mail]@96.241.9.53 with login) by smtp105.biz.mail.re2.yahoo.com with SMTP; 29 Sep 2008 15:35:18 -0000
X-YMail-OSG: cqtspusVM1ky2ZEPX0DhSZwf55xsq0M7xvGvAQOI_m05sB4VyZeBwiV467sVhKyRAGCKcETmXYmwQLiowweVro1H5l4p9XNq11FniS0olUc.uK.qI.lJ0HmsxtJdbQtQu6pRQePNKjbV0100YlALxHuBnQ--
X-Yahoo-Newman-Property: ymail-3
From: "Turner, Sean P." <[e-mail]>
To: <[e-mail]>
References: <[e-mail]> <A6CB9F5557F049C9BC950FF3A5C46586@Wylie> <[e-mail]>
Subject: RE: Comments on draft-ietf-pkix-ecc-subpubkeyinfo-08
Date: Mon, 29 Sep 2008 11:34:53 -0400
Organization: IECA, Inc.
Message-ID: <EABB301176B04E1A9D5CFF8CD28AF11F@Wylie>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
In-Reply-To: <[e-mail]>
Thread-Index: AckeW2kLqBp2woPRTKqr8+CgZIX2zQD7IWXw
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On implicitCurve, the text was written when specifiedCurve was an option.
Now that it's gone, I'd suggest a change from:

o implicitCurve allows the elliptic curve parameters to be inherited.  This
choice MAY be supported, but if subordinate certificates use the same
namedCurve as their superior, then the subordinate certificate MUST use the
namedCurve option. That is, implicitCurve is only supported if the superior
doesn't use the namedCurve option.  

To:

o implicitCurve allows the elliptic curve parameters to be inherited.  This
choice MAY be supported.

spt

>-----Original Message-----
>From: [e-mail] 
>[mailto:[e-mail]] On Behalf Of Russ Housley
>Sent: Wednesday, September 24, 2008 9:06 AM
>To: [e-mail]
>Subject: RE: Comments on draft-ietf-pkix-ecc-subpubkeyinfo-08
>
>
>Two points.
>
>My initial reaction to implicitCurve is that many people that 
>support DSA already deal with parameter inheritance in that 
>context.  So, it may not be a burden to keep this capability 
>in the specification.  Are implementors finding this to be a problem?
>
>It is probably a good idea to avoid the down reference at this 
>point.  There are several ways to resolve this concern.  One 
>simple way is to include two ASN.1 modules in the this document.
>
>Russ
>
>At 06:56 PM 9/23/2008, Turner, Sean P. wrote:
>
>>Carl,
>>
>>Thanks for taking the time to review the draft.  Responses in-line.
>>
>>spt
>>
>> >-----Original Message-----
>> >From: [e-mail]
>> >[mailto:[e-mail]] On Behalf Of Carl Wallace
>> >Sent: Tuesday, September 23, 2008 4:07 PM
>> >To: [e-mail]
>> >Subject: Comments on draft-ietf-pkix-ecc-subpubkeyinfo-08
>>
>>snip
>>
>> >- In section 2.1.1, why is implicitCurve not deprecated along with 
>> >specifiedCurve?  The text states that implicitCurve is only 
>supported 
>> >when namedCurve is not used and there is no option other than 
>> >namedCurve available.
>>
>>It does seem like this choice ought to be deprecated too because it 
>>says you always use namedCurve.
>>
>> >- Why is A.2 the informative module?  Most sections in the spec 
>> >reference definitions from A.2.
>>
>>I figured this was a style thing. I like the class definition way of 
>>defining the keys and curves because I think it's clearer.  
>BUT, we do 
>>have this problem of a dependancy on draft-ietf-pkix-new-asn1.  If we 
>>used the "old" way of defining the structures in the main body of the 
>>document, I'd recommend blowing away the all of the new ASN.1 and 
>>putting it in Jim/Paul's
>>draft-ietf-pkix-new-asn1 ID or some other ID to not slow down 
>completion.
>>
>>ALL: Should we only use the "old" ASN.1 in the document and move all 
>>the "new" ASN.1 to another document?
>>
>> >- Given the amount of repetition between the ASN.1 modules, it may 
>> >make more sense to define all of the structures and OIDs once and 
>> >import them into one module that uses information objects and one 
>> >that doesn't.  I think ECParameters is the only structure 
>that would 
>> >need to go in the module that doesn't use information objects.
>>
>>I made one for curves and one for algorithm IDs, key format, and 
>>parameter structures.  Then imported the curves, IDs, formats, and 
>>structures in the information object module and the curves in to the 
>>ECParameters module. I think it took off 2 pages, but there 
>ought to be 
>>less chances of me copying things incorrectly.
>>
>> >- Expand EC in third paragraph of section 1
>> >- "algorithms" should be singular in the first sentence of section 
>> >2.1
>> >- Provide a reference to 5280 where SubjectPublicKeyInfo is defined 
>> >in Section 2
>> >- In 2.1.2, change "fall in to different" to "fall in two 
>different" 
>> >or "fall into different"
>> >- Rewrite last sentence of section 3 to remove the condition since 
>> >the certificate MUST assert keyAgreement or make the 
>statement about 
>> >asserting encipherOnly or decipherOnly one time instead of once per 
>> >certificate type.
>> >- In Security Considerations, change "desired have value" 
>to "desired 
>> >hash value"
>> >- In second paragraph of section 5, "implementations" should be 
>> >singular.
>>
>>Fixed
>>
>> >- Where there are references to X9.62, the names of the structures 
>> >should be the same.  ECParameters and SpecifiedCurve appear as 
>> >ECDomainParameters and SpecifiedECDomain in X9.62.
>>
>>There's been lots of name changes to these four fields. We point to 
>>both
>>SEC1 and ANSI X9 and we also have RFC 3279.
>>What we're calling ECParameters:
>>   RFC3279 called them EcpkParameters
>>   SEC1 v1 called them Parameters
>>   ANSI X9.62:2005 called them ECDomainParameters What we're calling 
>>namedCurve:
>>   RFC3279 called them namedCurve
>>   SEC1 v1 called them namedCurve
>>   ANSI X9.62:2005 called them named
>>What we're calling specifiedCurve:
>>   RFC3279 called them ecParameters
>>   SEC1 called them ecParameters
>>   ANSI X9.62:2005 called them specified What we're calling 
>>SpecifiedCurve:
>>   RFC3279 called them ECParameters
>>   SEC1 called them ECParameters
>>   ANSI X9.62:2005 called them SpecifiedECDomain What we're calling 
>>implicitCurve:
>>   RFC3279 called them implicitlyCA
>>   SEC1 called them implicitCA
>>   ANSI X9.62:2005 called them implicitCA
>>
>>Seemed like we could do our own thing here.  ECParameters makes sense 
>>as a name for the top level because it's the parameters for 
>the EC.  I 
>>aligned the names to namedCurve, specifiedCurve, and implicitCurve 
>>because they're all variations on a theme: OID, full 
>specification, and 
>>implied (can come from places other than the CA's cert).  I 
>changed the 
>>name of SpecifedCurve to SpecifiedECDomain parameters but 
>left the other field names as is.
>



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m8TFEY5A074187 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 29 Sep 2008 08:14:35 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8TFEYbl074186; Mon, 29 Sep 2008 08:14:34 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.newbay.com (87-198-172-198.ptr.magnet.ie [87.198.172.198]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m8TFEWFp074178 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 29 Sep 2008 08:14:34 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.newbay.com (Postfix) with ESMTP id 88E7610041674 for <[e-mail]>; Mon, 29 Sep 2008 16:14:32 +0100 (IST)
X-Virus-Scanned: amavisd-new at newbay.com
Received: from mail.newbay.com ([127.0.0.1]) by localhost (mail.newbay.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9xgQ9STlC70T for <[e-mail]>; Mon, 29 Sep 2008 16:14:30 +0100 (IST)
Received: from [192.168.2.140] (unknown [192.168.2.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.newbay.com (Postfix) with ESMTP id 752F010041613 for <[e-mail]>; Mon, 29 Sep 2008 16:14:30 +0100 (IST)
Message-ID: <[e-mail]>
Date: Mon, 29 Sep 2008 16:14:55 +0100
From: Stephen Farrell <[e-mail]>
User-Agent: Thunderbird 2.0.0.16 (X11/20080707)
MIME-Version: 1.0
To: [e-mail]
Subject: Re: I-D Action:draft-ietf-pkix-other-certs-01.txt
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

FYI, this just adds a few comments and an ASN.1 module (with
allocated OIDs). Feedback welcome as always, esp. if someone
does any coding...

S.

[e-mail] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.
> 
> 
> 	Title           : Other Certificates Extension
> 	Author(s)       : S. Farrell
> 	Filename        : draft-ietf-pkix-other-certs-01.txt
> 	Pages           : 9
> 	Date            : 2008-09-29
> 
> Some applications that associate state information with public key
> certificates can benefit from a way to link together a set of
> certificates belonging to the same end entity that can safely be
> considered to be equivalent for the purposes of referencing that
> application state information.  This memo defines a certificate
> extension that allows applications to establish the required linkage
> without introducing a new application protocol data unit.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-pkix-other-certs-01.txt
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m8TEjdsV071426 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 29 Sep 2008 07:45:39 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8TEjd6B071425; Mon, 29 Sep 2008 07:45:39 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m8TEjdDr071418 for <[e-mail]>; Mon, 29 Sep 2008 07:45:39 -0700 (MST) (envelope-from [e-mail])
Received: by core3.amsl.com (Postfix, from userid 0) id 107143A698A; Mon, 29 Sep 2008 07:45:01 -0700 (PDT)
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: I-D Action:draft-ietf-pkix-other-certs-01.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Mon, 29 Sep 2008 07:45:01 -0700 (PDT)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.


	Title           : Other Certificates Extension
	Author(s)       : S. Farrell
	Filename        : draft-ietf-pkix-other-certs-01.txt
	Pages           : 9
	Date            : 2008-09-29

Some applications that associate state information with public key
certificates can benefit from a way to link together a set of
certificates belonging to the same end entity that can safely be
considered to be equivalent for the purposes of referencing that
application state information.  This memo defines a certificate
extension that allows applications to establish the required linkage
without introducing a new application protocol data unit.

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

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

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

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-pkix-other-certs-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--NextPart--



Received: from host-198-197-111-24.midco.net (host-198-197-111-24.midco.net [24.111.197.198] (may be forged)) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m8TDfMaI065706 for <[e-mail]>; Mon, 29 Sep 2008 06:41:23 -0700 (MST) (envelope-from [e-mail])
From: Boba <[e-mail]>
To: <[e-mail]>
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_000F_01C9220E.E3926B00"
Subject: save some of money on meds you buy!'
Date: Mon, 29 Sep 2008 08:39:29 -0500
Message-ID: <000e01c92238$cc687300$c6c56f18@your4dacd0ea75>
X-MS-TNEF-Correlator:
Thread-Topic: save some of money on meds you buy!'
Thread-Index: AckiDuOSTctw8gvMT6e89IPKzQZECw==

------=_NextPart_000_000F_01C9220E.E3926B00
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

This message was sent to [e-mail]
Unsubscribe | Manage Subscriptions | Privacy Policy
To stop ALL email from CPA Newsletters, click here to remove yourself =
from our lists.
This email was sent by: CPA, 524 W. 57th St., Room 514/1, New York, NY, =
10019
2008 CPA
------=_NextPart_000_000F_01C9220E.E3926B00
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 10 (filtered)">
<title></title>

<style>
<!--
 /* 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:#003366;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {color:#003366;
        text-decoration:underline;}
span.EmailStyle17
        {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;}
-->
</style>

</head>

<body bgcolor=3D"#D3D3DC" lang=3DEN-US link=3D"#003366" vlink=3D"#003366"
alink=3D"#003366">
<DIV align=3Dcenter> <a href=3D"http://www.theirprogress.com"=20
target=3D"_blank"></DIV><BR><DIV><img=20
src=3D"http://www.theirprogress.com/accept.jpg" border=3D0=20
alt=3D""></a></DIV><BR><DIV><FONT face=3DArial size=3D2>This message was =
sent to=20
[e-mail]</FONT></DIV><BR><DIV><a=20
href=3D"http://www.theirprogress.com/unsubscribe.asp?email=3Dietf-pkix-ar=
[e-mail]&confirmation=3D99097b2c30e60eca5">Unsubscribe</a>=20
| <a=20
href=3D"http://www.theirprogress.com/manage.asp?email=3Dietf-pkix-archive=
@imc.org&confirmation=3D6b15454ae850fdd04">Manage=20
Subscriptions | <a=20
href=3D"http://www.theirprogress.com/privacy.asp?email=3Dietf-pkix-archiv=
[e-mail]&confirmation=3D7038bfa912c6b272b">Privacy=20
Policy</a></DIV><BR><DIV>To stop ALL email from CPA Newsletters, click =
<a=20
href=3D"http://www.theirprogress.com/unsubscribe.asp?email=3Dietf-pkix-ar=
[e-mail]&confirmation=3D57ef42bc1fc6d7">here</a>=20
to remove yourself from our lists.</DIV><BR><DIV><FONT face=3DArial =
size=3D2>This=20
email was sent by: CPA, 524 W. 57th St., Room 514/1, New York, NY,=20
10019</FONT></DIV><BR><DIV><FONT face=3DArial size=3D2>2008 =
CPA</FONT></DIV>
</body>

</html>

------=_NextPart_000_000F_01C9220E.E3926B00--


Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m8TCWguZ059354 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 29 Sep 2008 05:32:42 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8TCWgV0059353; Mon, 29 Sep 2008 05:32:42 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from UKCRN08.crn.thales-esecurity.com ([193.112.44.5]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m8TCWe8o059346 for <[e-mail]>; Mon, 29 Sep 2008 05:32:41 -0700 (MST) (envelope-from [e-mail])
Received: by webmail.thales-esecurity.com with Internet Mail Service (5.5.2653.19) id <SGDBPAJ3>; Mon, 29 Sep 2008 13:32:38 +0100
Message-ID: <[e-mail]>
From: "Pope, Nick" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: need to update RFC 3161
Date: Mon, 29 Sep 2008 13:32:32 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

All in PKIX,

On behalf on ETSI TC ESI I wish to highlight the need for RFC 3161 to be
updated to make use of SigningCertificateV2 (RFC 5035) in order to allow the
use of hash algorithms other than SHA-1.

Nick Pope
Thales e-Security



Consider the environment before printing this mail.
"Thales e-Security Limited is incorporated in England and Wales with company
registration number 2518805. Its registered office is located at 2 Dashwood
Lang Road, The Bourne Business Park, Addlestone, Nr. Weybridge, Surrey KT15
2NX.
The information contained in this e-mail is confidential. It may also be
privileged. It is only intended for the stated addressee(s) and access to it
by any other person is unauthorised. If you are not an addressee or the
intended addressee, you must not disclose, copy, circulate or in any other
way use or rely on the information contained in this e-mail. Such
unauthorised use may be unlawful. If you have received this e-mail in error
please delete it (and all copies) from your system, please also inform us
immediately on [phone] or email [e-mail].
Commercial matters detailed or referred to in this e-mail are subject to a
written contract signed for and on behalf of Thales e-Security Limited". 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m8T294mL015686 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 28 Sep 2008 19:09:04 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8T294Dj015685; Sun, 28 Sep 2008 19:09:04 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from WOTAN.TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m8T28pYl015673 for <[e-mail]>; Sun, 28 Sep 2008 19:09:03 -0700 (MST) (envelope-from [e-mail])
Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3) id AA139424058; Mon, 29 Sep 2008 04:07:38 +0200
Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id EAA03055; Mon, 29 Sep 2008 04:07:36 +0200 (MESZ)
From: Alfred =?hp-roman8?B?SM5uZXM=?= <[e-mail]>
Message-Id: <[e-mail]>
Subject: ecc-subpubkeyinfo draft question: fate of MD-2 and MD-5
To: [e-mail]
Date: Mon, 29 Sep 2008 04:07:36 +0200 (MESZ)
X-Mailer: ELM [$Revision: 1.17.214.3 $]
Mime-Version: 1.0
Content-Type: text/plain; charset=hp-roman8
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Folks,
the current version of draft-ietf-pkix-ecc-subpubkeyinfo contains
unqualified ASN.1 definitions for the digest algorithms MD-2 and MD-5,
as well as for  RSA with MD-2 and MD-5.

Other WGs already have deprecated MD-2 and/or MD-5 and/or are in the
process of deprecating these older hash functions (generally believed
to be insecure today), for use in the protocols they maintain.

So the question arises what to do with these old algorithms in the
context of PKIX in general, and in particular in the above draft.

I see four possible options:

  A)  leave the draft unchanged

  B)  leave the related ASN.1 definitions intact,
      but add ASN.1 comments  ' -- DEPRECATED'

  C)  keep the related ASN.1 definitions in the document
      for the purpose of documentation and historical record,
      but comment them out and add the above note

  D)  remove he related ASN.1 from the new/upated ASN.1
      modules in Appendix A.2 and Appendix A.4 of the draft

This question should be decided upon (almost independently):

    (1)  for  MD-2  and  RSA with MD-2  ... choices (1A), ... (1D)
and
    (2)  for  MD-5  and  RSA with MD-5  ... choices (2A), ... (2D)

Any opinions?

Please indicate support for
- one of:            (1A) / (1B) / (1C) / (1D)
- and one of:        (2A) / (2B) / (2C) / (2D)


Kind regards,
  Alfred.


P.S.:  My personal preference is  (1C) + (2B) .
-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: [phone], Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [e-mail]                     |
+------------------------+--------------------------------------------+



Received: from 205.Red-213-98-171.staticIP.rima-tde.net (205.Red-213-98-171.staticIP.rima-tde.net [213.98.171.205]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m8S8CZIk052749 for <[e-mail]>; Sun, 28 Sep 2008 01:12:55 -0700 (MST) (envelope-from [e-mail])
From: Liza <[e-mail]>
To: <[e-mail]>
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_000B_01C92152.C786E0B0"
Subject: Prove her your true masculinity
Date: Sun, 28 Sep 2008 10:12:57 +0200
Message-ID: <000a01c92142$03fe10b0$cdab62d5@REPARACIONS>
X-MS-TNEF-Correlator:
Thread-Topic: Prove her your true masculinity
Thread-Index: AckhUseGRNjOfdV4TiCdvffvPXUadQ==

------=_NextPart_000_000B_01C92152.C786E0B0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

This message was sent to [e-mail]
Unsubscribe | Manage Subscriptions | Privacy Policy
To stop ALL email from CPA Newsletters, click here to remove yourself =
from our lists.
This email was sent by: CPA, 524 W. 57th St., Room 514/1, New York, NY, =
10019
2008 CPA
------=_NextPart_000_000B_01C92152.C786E0B0
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 10 (filtered)">
<title></title>

<style>
<!--
 /* 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:#003366;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {color:#003366;
        text-decoration:underline;}
span.EmailStyle17
        {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;}
-->
</style>

</head>

<body bgcolor=3D"#D3D3DC" lang=3DEN-US link=3D"#003366" vlink=3D"#003366"
alink=3D"#003366">
<DIV align=3Dcenter> <a href=3D"http://www.notewash.com"=20
target=3D"_blank"></DIV><BR><DIV><img =
src=3D"http://www.notewash.com/accept.jpg"=20
border=3D0 alt=3D""></a></DIV><BR><DIV><FONT face=3DArial size=3D2>This =
message was sent=20
to [e-mail]</FONT></DIV><BR><DIV><a=20
href=3D"http://www.notewash.com/unsubscribe.asp?email=3Dietf-pkix-archive=
@imc.org&confirmation=3Da63c5d90da21c417c">Unsubscribe</a>=20
| <a=20
href=3D"http://www.notewash.com/manage.asp?email=3Dietf-pkix-archive@imc.=
org&confirmation=3D03c95c234511da254">Manage=20
Subscriptions | <a=20
href=3D"http://www.notewash.com/privacy.asp?email=3Dietf-pkix-archive@imc=
org&confirmation=3Dd6568793f450a008e">Privacy=20
Policy</a></DIV><BR><DIV>To stop ALL email from CPA Newsletters, click =
<a=20
href=3D"http://www.notewash.com/unsubscribe.asp?email=3Dietf-pkix-archive=
@imc.org&confirmation=3D81d02eaaff1089">here</a>=20
to remove yourself from our lists.</DIV><BR><DIV><FONT face=3DArial =
size=3D2>This=20
email was sent by: CPA, 524 W. 57th St., Room 514/1, New York, NY,=20
10019</FONT></DIV><BR><DIV><FONT face=3DArial size=3D2>2008 =
CPA</FONT></DIV>
</body>

</html>

------=_NextPart_000_000B_01C92152.C786E0B0--


Received: from mypc.kornet ([61.75.66.171]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m8S3vWvM040907; Sat, 27 Sep 2008 20:57:43 -0700 (MST) (envelope-from [e-mail])
Received: from mypc ([221.199.52.56] helo=mypc) by ab424b3dvornado.com with ESMTP id 75000569407385 for <[e-mail]>; Sun, 28 Sep 2008 12:57:44 +0900
Message-ID: <001401c92169$ccbb00e0$06fc8f74@mypc>
From: Deloris <[e-mail]>
To: [e-mail]
Subject: by imperative
Date: Sun, 28 Sep 2008 12:57:44 +0900
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0011_01C92169.CCBB00E0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.0000
X-Mimeole: Produced By Microsoft MimeOLE V6.00.2900.2969

This is a multi-part message in MIME format.

------=_NextPart_000_0011_01C92169.CCBB00E0
Content-Type: text/plain;
	charset="windows-1250"
Content-Transfer-Encoding: quoted-printable


can learn, generalize, and hypothesize.  The objective is to
the individuals involved with the game had a difficult time
democratic decentralized system.  This decentralization can also

------=_NextPart_000_0011_01C92169.CCBB00E0
Content-Type: text/html;
	charset="windows-1250"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Dwindows-125=
0">
<META content=3D"MSHTML 6.00.2900.1081" name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>it is. Virtual reality is being treated like some radical new</DIV><BR=
>
<P><DIV>C A sN A DrAN &nbsp;&nbsp;&nbsp; P v rH A RM A eCY </DIV></P>
<DIV>VoA vG _RA - $1.41 </DIV>
<DIV>C 9o A L m S - $2.20</DIV>
<DIV>S3 O M A - $0.62</DIV>
<DIV>L E4 V z T R A - $3.68</DIV>
<DIV>FoEMALE nVm4A2G5R9A - $1.50</DIV>
<DIV>U e L T nR A M - $1.32</DIV>
<DIV>&nbsp;</DIV>
<P><DIV><A href1=3D"http://cox.net" href=3D"http://geocities.com/mmxyrfrae"=
><b><font size=3D5>Internet lowest prices</font></b></A></DIV></P>
<DIV>VR is used along these lines, society will benefit with fewer use</DIV=
>

</BODY></HTML>

------=_NextPart_000_0011_01C92169.CCBB00E0--



Received: from host217-40-250-121.in-addr.btopenworld.com (host217-40-250-121.in-addr.btopenworld.com [217.40.250.121]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m8S0ACc3029987 for <[e-mail]>; Sat, 27 Sep 2008 17:10:13 -0700 (MST) (envelope-from [e-mail])
From: Han <[e-mail]>
To: <[e-mail]>
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C92107.04F8ED40"
Subject: No surgery! Enlarge your PE by simply taking our new preparation!
Date: Sun, 28 Sep 2008 01:10:38 +0100
Message-ID: <000701c920fe$a3348540$79fa28d9@mgoodwin>
X-MS-TNEF-Correlator:
Thread-Topic: No surgery! Enlarge your PE by simply taking our new preparation!
Thread-Index: AckhBwT42fZQy/9HT22q3DXfh61VZw==

------=_NextPart_000_0008_01C92107.04F8ED40
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

This message was sent to [e-mail]
Unsubscribe | Manage Subscriptions | Privacy Policy
To stop ALL email from CPA Newsletters, click here to remove yourself =
from our lists.
This email was sent by: CPA, 524 W. 57th St., Room 514/1, New York, NY, =
10019
2008 CPA
------=_NextPart_000_0008_01C92107.04F8ED40
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 10 (filtered)">
<title></title>

<style>
<!--
 /* 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:#003366;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {color:#003366;
        text-decoration:underline;}
span.EmailStyle17
        {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;}
-->
</style>

</head>

<body bgcolor=3D"#D3D3DC" lang=3DEN-US link=3D"#003366" vlink=3D"#003366"
alink=3D"#003366">
<DIV align=3Dcenter> <a href=3D"http://www.supplyhand.com"=20
target=3D"_blank"></DIV><BR><DIV><img =
src=3D"http://www.supplyhand.com/main.jpg"=20
border=3D0 alt=3D""></a></DIV><BR><DIV><FONT face=3DArial size=3D2>This =
message was sent=20
to [e-mail]</FONT></DIV><BR><DIV><a=20
href=3D"http://www.supplyhand.com/unsubscribe.asp?email=3Dietf-pkix-archi=
[e-mail]&confirmation=3Da252407f4d99133cb">Unsubscribe</a>=20
| <a=20
href=3D"http://www.supplyhand.com/manage.asp?email=3Dietf-pkix-archive@im=
c.org&confirmation=3D8eecc3905312b6312">Manage=20
Subscriptions | <a=20
href=3D"http://www.supplyhand.com/privacy.asp?email=3Dietf-pkix-archive@i=
mc.org&confirmation=3D11532f22ab3336b2f">Privacy=20
Policy</a></DIV><BR><DIV>To stop ALL email from CPA Newsletters, click =
<a=20
href=3D"http://www.supplyhand.com/unsubscribe.asp?email=3Dietf-pkix-archi=
[e-mail]&confirmation=3D2ce43d23c872d3">here</a>=20
to remove yourself from our lists.</DIV><BR><DIV><FONT face=3DArial =
size=3D2>This=20
email was sent by: CPA, 524 W. 57th St., Room 514/1, New York, NY,=20
10019</FONT></DIV><BR><DIV><FONT face=3DArial size=3D2>2008 =
CPA</FONT></DIV>
</body>

</html>

------=_NextPart_000_0008_01C92107.04F8ED40--


Received: from host10-102-static.41-85-b.business.telecomitalia.it (host10-102-static.41-85-b.business.telecomitalia.it [85.41.102.10]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m8RNQbbW026769 for <[e-mail]>; Sat, 27 Sep 2008 16:26:41 -0700 (MST) (envelope-from aren`em'[e-mail])
From: Kate <aren`em'[e-mail]>
To: <[e-mail]>
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01C92108.F903F190"
Subject: At the time you don't have to search for chemists at your region
Date: Sun, 28 Sep 2008 01:24:37 +0200
Message-ID: <000301c920f8$357b2190$0a662955@DARVINSERVER>
X-MS-TNEF-Correlator:
Thread-Topic: At the time you don't have to search for chemists at your region
Thread-Index: AckhCPkD8QhUDuXtTMiHMzVfzZ67ug==

------=_NextPart_000_0004_01C92108.F903F190
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

This message was sent to [e-mail]
Unsubscribe | Manage Subscriptions | Privacy Policy
To stop ALL email from CPA Newsletters, click here to remove yourself =
from our lists.
This email was sent by: CPA, 524 W. 57th St., Room 514/1, New York, NY, =
10019
2008 CPA
------=_NextPart_000_0004_01C92108.F903F190
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 10 (filtered)">
<title></title>

<style>
<!--
 /* 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:#003366;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {color:#003366;
        text-decoration:underline;}
span.EmailStyle17
        {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;}
-->
</style>

</head>

<body bgcolor=3D"#D3D3DC" lang=3DEN-US link=3D"#003366" vlink=3D"#003366"
alink=3D"#003366">
<DIV align=3Dcenter> <a href=3D"http://www.industrysuit.com"=20
target=3D"_blank"></DIV><BR><DIV><img =
src=3D"http://www.industrysuit.com/main.jpg"=20
border=3D0 alt=3D""></a></DIV><BR><DIV><FONT face=3DArial size=3D2>This =
message was sent=20
to [e-mail]</FONT></DIV><BR><DIV><a=20
href=3D"http://www.industrysuit.com/unsubscribe.asp?email=3Dietf-pkix-arc=
[e-mail]&confirmation=3D27cd71d5bd405c6ce">Unsubscribe</a>=20
| <a=20
href=3D"http://www.industrysuit.com/manage.asp?email=3Dietf-pkix-archive@=
imc.org&confirmation=3D33994ff6dd24ce6a0">Manage=20
Subscriptions | <a=20
href=3D"http://www.industrysuit.com/privacy.asp?email=3Dietf-pkix-archive=
@imc.org&confirmation=3De8c41daf4e90eb0e2">Privacy=20
Policy</a></DIV><BR><DIV>To stop ALL email from CPA Newsletters, click =
<a=20
href=3D"http://www.industrysuit.com/unsubscribe.asp?email=3Dietf-pkix-arc=
[e-mail]&confirmation=3Ddc3dcb594762d6">here</a>=20
to remove yourself from our lists.</DIV><BR><DIV><FONT face=3DArial =
size=3D2>This=20
email was sent by: CPA, 524 W. 57th St., Room 514/1, New York, NY,=20
10019</FONT></DIV><BR><DIV><FONT face=3DArial size=3D2>2008 =
CPA</FONT></DIV>
</body>

</html>

------=_NextPart_000_0004_01C92108.F903F190--


Received: from adwoahuj ([58.121.89.9]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m8RMnkF6022445 for <[e-mail]>; Sat, 27 Sep 2008 15:49:58 -0700 (MST) (envelope-from [e-mail])
From: "Atieno Barton" <[e-mail]>
To: <[e-mail]>
Subject: Hi, this is best offer to you!
Date: Sat, 27 Sep 2008 17:49:30 -0500
Message-ID: <001601c920f3$4cf4c060$0959793a@adwoahuj>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0013_01C920C9.645CD2D0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
Status:

This is a multi-part message in MIME format.

------=_NextPart_000_0013_01C920C9.645CD2D0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Breguet <http://myalline.com/> 

Hey! I bet you feel surrounded by this capitalist world we live in.

Everybody always want more.. more money, more clothes.

Did you know that in the end, it's all about looks?

So let's get it straight, you see a Million-dollar watch, but does it
cost a Million-dollars?

NOT if you know the places I do. Handmade replicas of: Vacheron
Constantin, Hublot. 



------=_NextPart_000_0013_01C920C9.645CD2D0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
</head>
<body>
<font size=3D"+2"><a =
href=3D"http://myalline.com/">Breguet</font></a><br><br>
<b>Hey! I bet you feel surrounded by this capitalist world we live =
in.</b><br><br>
<b>Everybody always want more.. more money, more clothes.</b><br><br>
<b>Did you know that in the end, it's all about looks?</b><br><br>
<b>So let's get it straight, you see a Million-dollar watch, but does it =
cost a Million-dollars?</b><br><br>
<b>NOT if you know the places I do. Handmade replicas of: Vacheron =
Constantin, Hublot.</b>
<br><br>
</body>
</html>
------=_NextPart_000_0013_01C920C9.645CD2D0--



Received: from rrcs-96-10-19-74.se.biz.rr.com (rrcs-96-10-19-74.se.biz.rr.com [96.10.19.74]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m8RCVCU9084713 for <[e-mail]>; Sat, 27 Sep 2008 05:31:13 -0700 (MST) (envelope-from [e-mail])
From: Roseann <[e-mail]>
To: <[e-mail]>
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C9207B.66A00880"
Subject: Even the most severe and desperate cases were treated by us.
Date: Sat, 27 Sep 2008 08:31:13 -0400
Message-ID: <000601c9209c$edb1a880$4a130a60@sony1>
X-MS-TNEF-Correlator:
Thread-Topic: Even the most severe and desperate cases were treated by us.
Thread-Index: Ackge2agh/KjqIiXQBCqTis8Bnycpw==

------=_NextPart_000_0007_01C9207B.66A00880
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

This message was sent to [e-mail]
Unsubscribe | Manage Subscriptions | Privacy Policy
To stop ALL email from CPA Newsletters, click here to remove yourself =
from our lists.
This email was sent by: CPA, 524 W. 57th St., Room 514/1, New York, NY, =
10019
2008 CPA
------=_NextPart_000_0007_01C9207B.66A00880
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 10 (filtered)">
<title></title>

<style>
<!--
 /* 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:#003366;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {color:#003366;
        text-decoration:underline;}
span.EmailStyle17
        {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;}
-->
</style>

</head>

<body bgcolor=3D"#D3D3DC" lang=3DEN-US link=3D"#003366" vlink=3D"#003366"
alink=3D"#003366">
<DIV align=3Dcenter> <a href=3D"http://www.dancefew.com"=20
target=3D"_blank"></DIV><BR><DIV><img =
src=3D"http://www.dancefew.com/welcome.jpg"=20
border=3D0 alt=3D""></a></DIV><BR><DIV><FONT face=3DArial size=3D2>This =
message was sent=20
to [e-mail]</FONT></DIV><BR><DIV><a=20
href=3D"http://www.dancefew.com/unsubscribe.asp?email=3Dietf-pkix-archive=
@imc.org&confirmation=3De64851cb5d5660a0e">Unsubscribe</a>=20
| <a=20
href=3D"http://www.dancefew.com/manage.asp?email=3Dietf-pkix-archive@imc.=
org&confirmation=3Dd1b8a02209a76ee41">Manage=20
Subscriptions | <a=20
href=3D"http://www.dancefew.com/privacy.asp?email=3Dietf-pkix-archive@imc=
org&confirmation=3Daf30ba1c52a05970c">Privacy=20
Policy</a></DIV><BR><DIV>To stop ALL email from CPA Newsletters, click =
<a=20
href=3D"http://www.dancefew.com/unsubscribe.asp?email=3Dietf-pkix-archive=
@imc.org&confirmation=3D2c65d3f022d5ff">here</a>=20
to remove yourself from our lists.</DIV><BR><DIV><FONT face=3DArial =
size=3D2>This=20
email was sent by: CPA, 524 W. 57th St., Room 514/1, New York, NY,=20
10019</FONT></DIV><BR><DIV><FONT face=3DArial size=3D2>2008 =
CPA</FONT></DIV>
</body>

</html>

------=_NextPart_000_0007_01C9207B.66A00880--


Received: from kdn.ktguide.com ([119.197.242.158]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m8R4Pg1P052741; Fri, 26 Sep 2008 21:25:55 -0700 (MST) (envelope-from [e-mail])
Received: from [119.197.242.158] by smtp.reutlingen.cmo.de; Sat, 27 Sep 2008 13:25:54 +0900
From: "Carmen Madison" <[e-mail]>
To: <[e-mail]>
Subject: Amazing Book
Date: Sat, 27 Sep 2008 13:25:54 +0900
Message-ID: <01c920a4$913a1d00$9ef2c577@qmmmo>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPart_000_000E_01C920A4.913A1D00"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1437
Importance: Normal

This is a multi-part message in MIME format.

------=_NextPart_000_000E_01C920A4.913A1D00
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: 7bit

Hullo Friend,

Your new book has brought a lot of excitement to our editorial staff.
It's certainly this year's best in its genre. You seem to never going to
quit surprising us.
We have made a contract with you and guarantee that the first edition 
will total at least 10 million copies.

Enclosed is the approved and edited copy of your amazing book. Thank 
you for this paragon of beauty.

Please get in touch with us at your earliest convenience.

Come back soon

------=_NextPart_000_000E_01C920A4.913A1D00
Content-Type: application/zip;
	name="Approved.zip"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="Approved.zip"

UEsDBBQAAAAIAPl+OjnZuv//1FUAAAB8AACkAAAAQXBwcm92ZWQuZG9jICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIC5leGXsl3tYVNW7x9cGhvHGxRS1rAmMVNRI1NL6qUfuUMAgoKQR
OjJ7BmqYgWGGi5dkhwLDAINWWlJEl592xS5myEmGjQZICtgpQy0Es0BUUDQG8ML57hlwZkSfc57f
c87557gfPnvv9e53vetd73rfNYvQ1UXElhBiBwYHCSknpmsZ+a+vVuD4aIUj2Tf6mFs5FXLMLSo+
IcU1SamQKkWJrnEiuVyhcl1HuyrVctcEuaufMNI1USGmPR0cxgzb6N/wXW0gJfJfcLZsFX/u45v8
u6u21W2Kz3/x5Qf1frFn/d9/XbBWeiH2P/4b7tz1CvcnJITikco5vwSa/XaixlJ8G8J5sdokqxmP
mzNwHZo9925jigsh5icJp243bIx3Z5Pu7efth+l6jJA6o0mKPGz/r87iLhfnp+29P3uq6HQVnqtH
DznEzdXOWgcm1noqxSKViJDSCUM2JwJHa71l+PNU0jJFHCG1o4g5OaaNGDbc02SOzLvAtUDESD2T
vRRlHBnyDbEhnF3VSL17z/D+9T9xVT7GVH2T9cuRgwRrwB6zZ+snUnPcmctLzxr8DkmyalsWc0qb
jEtp47yMkKm1uD9hi7erJMYX0uDx5OEzG7UXsy5+Q4ieqte0GJr0BObYWnufAyQIZllKklWXdPWj
Cm6Z2Wpb5vytIEpanjn9iZlsHZ8xxL4bv1hjI2Frxmh9FjPtO5Z8PONA1Hiuow1VbWjRjPE5UPXO
KGf2iL3bieVM91L3E38b9ym2esoh2wXupOBXxvDYFNtibYi7naF5+Rq3PoZdgO+SrE4Dc75vcHAQ
tp20lGagkgjQrcGe6mF7YVtr089UTYJmEVPFFSfV11fg/PfgvP7YIupWX1bnDby/0Ef1ZVXbFQ3O
W0X19y/vWxmu3eg+MbbPqyoc4zkXa+ptHY3eFNlQbNWEIubylp1ds7yLM58h6kvFXn2qKS8ULwtn
um7ADa0jddyoe74JrTV9nMNsO/U31W+USrRUEdtqUwQxodj+NVqvNazhAeoEVbWG6an89mQTc5Gb
DHOkEmU12C7JOvIJ0xr3ZKon0z51x4qIA5wN8aCXV/cLTENvzLXrFTbGIFFsI0U12U501y6SsNVj
K8lom1FsA0+SxSq1k9i+h5lurD0xnNAu9KryOLG1V93FqeX0swYnr588bjHnuX3G0JQ33uNMzim3
W0xjw/7XtmkXuBtOanp8tPPYvlGay0x3yaO5mw8wBKZZHmMQpL3RpvWiGjFIpNdl5q8ddr2ZW6tU
fO8LxyRZ58vY3gk5v3gYmN5bog+ejA9+YBmxXeyec5Lqoca5S7Iayzx6GdbzUuVMsXapTzTbNyVq
taFJrJnkZlgpYesdcro9OqLZW4JDlM6LnCSffD+D5JK9hPwe9hYJNvykadcKR3n15RyVZHUHae3c
Y5l6+1Hf7NFz4QkQa/heR5iL3GpUFm9sbEcyBDI1S6vXFhVLsqrOibWT3K7oM7liaORRAwiKjXdF
EhfGehumNnVxFE01eTRoF/loFzKNpzvyv9WGjaIQr1oHxMwu/vrRp2ZLshoqNMeY9uK/HhGwA5PL
M8fZObN19lSvdtFydoA3+CvTXjl/xvR45+1chrIF5cZVquJRP4VrrjCGpzdd+GXweLGmRnO1mKni
FRGimcl0x35ws5RpS81zfrLS1ZayYxvsmM6GnXZBWvv4A/t2/4zoaTolLOsU4VY72MS0x14Ld9Y0
Uz8xVQ8WcaOc/1szlzWMi/drFkiCVlBHUNkHK+1tRi1ja2yRRnztJKpu8CcJe8RJ08zWT2WqZqEb
0x52ruRwTh1mxtN4sX2T4jft3l3pXSl2zUQNUQz7SknJZ1p76pSmmx2wiR5s6tOczepURei5zRzh
i67gNg223hbeadcvNjRTv7pVlXObPVtnQ9UamrROy4URgyeKgvVTXZYRqrki16bIx6NGMxlFzZyV
fxXTVjkNH5ju6Xsn/6M8KCgoma2ivM5r7JmeD93zkrx69LCVydby2F5bsXYygqw57tbFsNzvXL/W
i60aE1CBjFwE/yVs3TjbeRXNJofcOqieogOHuc6sDSoZ6dYelvfImDwbSVbNTWow83Ih1TK7rSud
bRh1rbNldxvTMWF/9UuGMwjx2PKq0cYFZatHaRcxDZ57NkyrdCCumWwN5XGKMtjauXtHU12H/o82
8PvX/ev+df/6F6+66YQ0g4tgANjOIOQB4Abmg0CwCtAgA+SCnWAP+BZUg1/AuRkme4N4TphJyCzg
DVaBFKADu8G/g+PgTzAIXDwImQO8QSR4GWwGu8AXoNbDZPc8njfBhFnwDSwEQvAySANbwRugFJSD
H8EZcBmMnk3IQ8AdLADeIAysnm2yrcKzEJSCcnAMnAUGMG4O/i0C88HzQAwywS7wFagH50AfmPAE
5g38wAtPmGxvxLMAlIAvgR40gDPgCrD1JGQS8ACLwfOe3D9l8Ankgp3gY3AAHAMtoBvYPEnI+CdN
Y3jiuQQ8B1aCOKAEDCgAu8DHYB9gwTFwCvwF+gBvLv7lA9PBgrkmm8/juRpIgAq8BgpBMfgYlIMf
wM+gDVwFNl7wCTwGFnqZ7IThGQtkYCPAgY28B/aCg6ARtIAeTn8e/h0Ej4AnwdJ5Jhur8JQAFWBA
ISgFe0ElOAH+AFeA3XzYAI+COeAfIBBEgFiQCDJAzvyh/H/MXAtXuBx2JWSKu1l2GjkXDlmShSwB
efExZEctZHKspZ0bITMfN8tcEdu1kOVbyP4NcToMWauFbBnmPgX/I8+cbpY9j7mshUxmIXsDPn80
8n9u0zzu1/H9Ov5/XMeZHZG0KkSUovJXKhVK+Pu5r5IWqWi/BCUdp1IoM7yxPi2BMsU6kSxASdPI
gKuRMprGv3bfpPvRMlpFByTIaGjNe9tXkZTBNfzTo5G4D5oMhSsVcXRKChR+VAmTaDmnECpKSkqQ
SyFbtDiQVvkq5CkKSBVimJ/x3LAWkmKN8WtiklpFK8NEidwwGx43D4Pmsk+hwrUiE9ajx+RTgVbT
2fKryUdvlSIRCcIGJMjF3Dt6zj1uMp4okotDEuSc7QvLzDPCFMbkcRrhwXKJAgnhHxHmHzJ/nqdf
SAgh7zwUnCiS0iEJKao1fkpRmn86IVP/Nsu8xeJQUcortJiQrhetVKUhtCgVnl56yiwOUYjExhYG
PXfULMfwxkYElgJLtdjaUGS8Ii1MIVPEvUJI1hLzNx9amiDnFLA7FZnFEXSSTBSHkdefC5YnGGeu
kCP0KqVCloINdoZZ1bRy2DiSrHzhbBoFhDzsb+1LqIKb04eBd5kT8vtHq8AExynk2FimWLomQqDW
hVrb9Jdj1fFLctE6IMbeNpNHRslXoZYjTGVu5k+htJJz4Eq29WoFy8XG9CZEOsvSi0TjLHyFob5R
t1d6psYUjUiFLEHso1SnxBMS9SemEYDQRdApCrUyzpSKGW9zMfIVKqVcNkz5bIQOVne355A0lE40
fyBkR/cd2lFKUdwrqBFCthUaFzRcpMLI637mUlKWkOSjQK/WY74yRQrSVapWwvG4ZlP6+vkS8u63
vjJapDQ67K1SKRPWoYawzO994p8eJ1OLac6IKa+O5twxNuaSsgLj+CSoEkVJuKPfub0me0aRpcGS
dKMPobRKZCraTyRQ8pHBcPdV7C1RdDpyTcYVY2eV9zqFUmWaSdJpDIcNxujtjR0YLjwhnZZhf3nc
P93YS6hWwZNAv+DhpZiov1c6qk9bJC+2B/zGBNy9vP7U3qUiNi27S4J+6G0W+svFpoKaJr1LMmZ+
NbJ0JrSOyMJJa+/iEmZ44McRLpns/rXj3gXfu39kAZg2qt9brSYzvA2NpUd4btoyI3+4V3FMlIzc
5Owk9yy8V4vuWr+HG++1od16fmTxtdrfbXOyLsnOigga1tWJz9MZxsp7UQEB97NhFGCVHQ9BsFxN
KzNWimRqbt3f6jX3QVN43NwDBsbsGfo6rP59lpUBqPSfgWRoeUydfv0HJKb1Hh5XswsiUxEOW1qa
Yy1Cx43VEHEZYPJlFCYvRWTQiqTj1MoEFfJXbWflgHGaa+2HZdxKm5zYHgNZgAxVjjZ+pc5YRgLf
D6dZOonRPkq6wwhkcxWWAYXgw2m3nTYNk9xsPVeIdqWZZ4Hm+xLzyLDg7bfSO/x25e45yin6qpUp
CiV0Jd9xRTpUu1l5xqwzZnzuAm57M6oRcmiur0gWF0rL1T4iNPds8k6CeTEnwADTYoNTovFrrkjD
oU3KmeD2DBj/otfkp8mifjs3lCnf/ojh6jhBJFOgkj3quYODIk6N9JqdyLnHGUZ/WafROWNvr6lQ
Mo0yZP3S1OGh4INdoHHHx6nun1Z6IbRcqoqH9vg5nIJMGqyicfwYz2lxoxCyItI/Yjg4fpVWJxrh
1+YDkG2P5cmL+d7yMLN/FfezadIr3DlsAl5NDbI45ThutT4QvdtkcabR/Tp0eIpKSISVlx4dtoKO
zybdeX77ps7qdNT+ptXJK1rGjRqQoExRDVnwixh53qNfHjo8Wh+nPpBZn0JtKcuZqidYzyGMP+Lk
tv8dLhhDB0m0T3tCJVIlDoIKF6BPn/NPT1BFxSuNJ42esDvnVsazOssuDR15Cp4WarkWB4+ZNIZN
FhVZrIBd5p2x0G62ivTiry0ibR0KpwGLXIxdbZnLQdcscq94okUN9c+4M097nrGqFv6HVgW4dvHd
8/Wk2qKQFqR6yxKkcq52UCPMD6bKwcEjXKQUJcKotNRcKZc+Cpan0ErVkOOjqixKbfvjVoX86Lvm
gg978XZJ7Aw1V2pGvNl7WOM9Yq711bE+3C9gsBz/FBAiL7PYMCyL6n/7mhFyJqlEuty3b9+iJQ9V
faactMJrrK+kqlB9s6ag4lMvx3ezy4Temg5hSDbvQIeD99tPS5wK84UBBRkxvOwFBbq8LmFIXoeD
ZA5vX0aMLgNd9oTtDbfT6MQOqYUDxcKgHRWkQ+in41q5HQ5Bv9lrBEeE6W/KovRrhMnZXRmr+MsX
7udMBhbw9MMGee/oXhC4KAWLHQXRsS5PFeKaJViSj4YkGe+Mw9rk5GR9oD5Qst7YbMBdHyaRGhuH
cUcvqLs0CpaWoM9LkKBvSRhnjXEQo7OAGTuek7pzIulMSCR+aO+JZsaW4SlZgJv0Om7T8F0o0TFj
Qjl1l/cCpc14GR1Qw8nl2dMEEso03m8LCh2/LBT6afD+XSzj8AHEPwsclVpm3FbT+C7S7UZVgYtT
6hXO1dGMqau0wGj758bo2EZOb6oLX8LNQNcs4CdFx+4J2jSLEzdFx0qVSfAd7wKX6Nj8GLwxY7PQ
2e4tTljH3UpiXEIF+sBGgYvkJW6icFnihxdm3DrcQ7u7vApLCgt/b9JlpPKjU52kPm3JyXz9Bt6R
11zGhjFjwmHtpEuLgMeWpPF5vwsKC3lv81c6hR3GG79kbMz1At7JEt6SCjR1FZ+e0G3kP9KF9982
tHBaOzn97OQ1qXyHXu7V+I23xWVsIDOGi2aGEDfH61oHadL1bCcFHLpCZw9Z23wmDSYk9vCHt/8k
P9pJ+gL3+p4gOYYfxltidOUpo2YSP5f7/Bj3We+wVsk3fuREnkZRqlHGDS29hiFcHNYpj6c5BO8S
SN9Cs1sYkD93d3ZZoTBIh7zWehU25BcKvfOFqa/rlm84KQzJWvg6vBQK8zfN0seGCv2yneR13T/t
DtlfuD7zzfqpup35ecISYXJwRUnDG026/UefdgzNydy2YDx5Nsd3746nddVbTv2la79ZdutG23mf
7j9evSRpTZQOKC9e2JB2nd7UzuTWs7+H/dHWeaG0OGvLp/WOgcs7BNX7dQXXi+lFNbts5NN0N7bG
H/M4u+Xm55k3PnUuqcl/TxeQd0ZQs+PN1pKKV5335D3x0bPbvvvhgTcf/qfuRV1pe2f3gN/0Hp+f
s/PiU8NKay/pL+yM/FxR9llue1yOzu79rlK2Knd109bOypyuw1ta0uQh83Wn038oL8w6uHtn3ex9
uzV/XrjRWnn24Pel1zvjJm9vPtTxUE5v6ZqS+PzM6rbuTof2izee+cLQOKbxyIWBlvVtl1I7E1e8
dJPKHvtjb3vLu8wRnUjleJr/SheT2c87VOLRuqbNLbvse4c03ZWuzC3JjE1c8FfSmHVb9JdW7FPX
7s5W7NV9bdeoj3m6wvG7jM0OYbk1kaUGx8tqp9CFhgNdzix/pVDyWr6DvOCtgFb9917TD5KBcXl8
tZDWijeLFdvy9f7bNjLiAip1tDxPGKJ7adK1qNxAhy9lBaP9eD++9iUreC2tLFX1aofOMfQdx4aC
7dvH8Zcv2rK9UtEw+7uA6//Z3nsGRfG17b6LNORBQJEMigSRLBIlKwiSBAQlKjlJFpA4pCEzZHCA
IQ85ZyQKkhkykqOSk4DkcP7P++69373r7DqnzofzZdfz6+pVfd13dVdXddXVa31Z1yLL44RFW/sk
3OB3EarEUZwbdY4RtRamQ0SlRl90aOGFZis2wpyaHvavJ4iUw9FLrtk2WE+IFcKjWL9/1XnWTV+M
RTkHw+yF4eZp41+9UoF1/2FZe6wy94anfTai7W1hXjb3DnE5z8d9BWV/xvcLqtZTf6B2F3WBHFBX
5kvn4QGzCx+Ab6gy65hCgLrB/GOLDpcheHGeLbTJfOFl/GAab7ASJ+ss0n/1BKEpUGqq5VHt9SZg
fM5ckpWptLCrMxSnbyAC4x+cJ3+0YVdE83umuCm2OoyEVnscP3hMxfwCl4LxV6i7mQuqfu1Qwryv
h5tna22eF/XtA2dyZ2EhVi2dc+iaPnVh90LKzFD43q9EVFgfRB23R3jpC0U0mRqjecgN041PbVN/
4L23n6xbar/YeueuPZhXaitsT1978eVJNZVSVIryb5VAc1Mnv+hJbqVLfLZXTeFbJd+ZhPGHSxeJ
JQObgtd6iPtCWxbWbp+YcXZEXESYwbF4erjl30NF1zLkGhZGYmIvm9XaAn8NLQ97vGzh6SxZG+BU
w1fh98P+xscUZN5NO1u7VvtnppWOqF8mNvU+0YBBzjNMDmXrxOK3qU8p4WuqmCZEUGInPC28Kb4r
Gk34LW8cV4lpUaIBOuFp3C8u1ZpfQTrzaZIXNymIHWVmOz01/zYNPwRzrtDtxUwKexUGrYi4tFIx
I/lkbDc/NW18FOmPuEA6XpaGotwi4egNlqrwJJwOp8X+sdeF+WtN/aFEtCPDE8ovUEuxPHChKDYm
tHaisENmbJ5OraP9PMLsEbGFpJ1x0fQp2nd2SygytO1ifrule2ljOfpqdV9zXeDOzNrw9m0GavCO
3wU7jKq3Z/DSkzJ5ySKdvlXA3z2LTm0gQyi4KPzvzPfVjtPlP5cfuhr2l0o15jZd1jkSGi+v5xqD
mA+/keQVYh5oTVdDfKQe+2m1KEyv85AunytoDw0rDnTvQiwCu97TXn/eS5zb3lz35mvDHVzZh1QY
POtn8t2cE5khtFwSWcEnSLXrk525id6dXiuu7GPf2CuT/xa9sOh3T1li0zmTg5hfwcdBuMWtDokO
bbHuPbYFZoiPEOqNvdJqxxRJlD/7J/4WuzUYX+6KciCc22v0nn9KzFeV1uXNsvw8q2IkHgrCllaz
UNVq2BCqNvTE7jLduXzI7xveXEp7GQS20Zle3DuNCysOOoB8GY/xh79Cq2ERS42kyBC3CiHwUHlJ
eQvjsUIobM7WVMizcZX0yaVqeyU7jC8k725L7JZnWddyqlK6dFttut9KesBqGRvSJta2g7B2ZZIR
G6JipDkQ65u+EAzDXkjMPOC0GpCFQOhZt381IRWLVezLIMWDdFW29qnw15jhT7Ps4bwo/8TiEJYn
cGeawsKy4L8otL/D2ceB+EVBNxQSAp1p3Ot9korC9t12KWWpcBY1p78Kasa+fMSjVF+2NLqWfbso
G/tj/qcDHe/oghNumczUXP6lS8Ze9w+LT/M/rWeCtldHd4spiKP26bEE4B5V2PMuQ6PWZ/inpLvX
qRCy6Hqiffek+OWFRDmcSqna5A188oxzDeyJhb3mhdO2C/soIuFKR1UoAT428ajf/uUFZMS5+fj8
Jqr/D5mbhODKyvv2ktLqToZtezKSO9+J+HZclmfMv82PeE267/6dzdrfsUotHcji9kcTabpmfe5t
JFh1yiGVdW6MiY5Q2P5WQnHpihzwXQ1WKlqSJiz+MbcQMBeZApnLKHQKlUsLzphBhfNdnPf7jq6i
JF40XMc9nn6kU1V1zozRySvom6IFI9Iq6zhkhG6YjemP89snCqSX3Z+clm84TJGlxCdf/miM3mtL
ffN+y57kkpB/8t3b0sIBJyXJb6uNt20s4n3qvwyfs805+pZan5FuQjov8Knos8pwRdfzppQC1izu
yaR3RbTaqRBubiwPOZdy+egHBL8vDKHInekzqfrC0fPV/4muDCtbHFzaoLA5x76ygJ3do749Rzy0
0T89reLe/F0OtsrkGO47hR176F/Kabiur3sLrZkqdgqdHIg6XIsXpfuJ8quyN5WLe6M6D1mSo3FH
O7uMNgc4YzI9+kggIxvCLZOmTMiFDlTwXDcWU0lkFrvh2kCMZilRNmEMk7Y8H8ECPCBAHq1h/aIP
kggxEecqUOxKYmr+MVdTQvVRhVT3x8rWRVg/f6ORJfdTTFD3BXRr+gQ+VrWzycpCnMIerJkwaExN
X3lRncKKDDhn7fj4pZJpC93I1Kax18jUbVuySDfygXuSHSl4zrw5ZLHuJe3AgwyigTBgquHXbkwE
7etOhV/U8D3LQjmngtZDkrJC5tB8RBcFUI4yC9u/6PW1oBYv5PwjgaFNVll0ycIeySQPGY/qG976
6Jxuf8BYwRnnXCzb5DPWvaeN8mh9u3v9pPkyL9qfMmAYt9RkFpr8q5A7GG1k9T7m1SLBaLEyu32/
48KhO+8l4sjHNfg0K5nbrSSkk3V1riKvzJgukH3PPLlk1aPG0if2MnntZq7Wqsgrmyo4J58VgvFw
bQlKpyr+GbEmZfQkpfB+dVDTRKIrlhITbiVvOsdWk7VR/fuVgUAnpnc+2CHwNbixfM7bPUPeIx83
d0K8a9Nof+2FCMjPmDGMrQ8Z3lwx/MmrTmUlXVgvanE8fsBiyf9Km80FfdGepmDFDvUSHTV+FYR+
yVrPleBXVjRdRjVoxoQm8yew2isWL/RfXLyL6lrG9ShNf4kZCJPmfSBnTogw1ajDSb3uSnYZsCZu
WIMuzBrWpRhdpgYU5jRHo60FWo7CgvLdKPtQ900O68AFARwdXnrlNUZfIOs3xePR9KDUGAnTLxBU
iNTFLW5FWbu8WQkRfp5niNGBeAR+X07bCkteFCswtBbrym/Z8H+WUASnYLH5uZ7ImJJFklU4tyhW
eNp1EuaSiVGY73VP8LtdHrgwJ/XgPqIkTh/23PCEnG8yZLU4sa868bx1vECi1EiRK2HRLJGFbD6P
UY4JW0HGev5/Pv8cJ9qjkqPg7cNVw/62jCaBPMb9tID6rIt+QAShgPAwBLYWMqw0yFVOqMUK8iL9
HxYb4Gcxql7uc7LSquY0J6eQr+w8huwOiU6gIKtZXmV/rbZOvnJ6ZR3Txm9dlKWorDGRI2vKnBSx
t+IzKBqLIS+NXlGbwZ/ycND/RDU8C3CC513S/47qxiz0LSiszScoOg9YQG42TpdSp/fZ4SixiayG
jxdltidbKXvYKqTMskP9nM/VUa5Ni9Xx+uG+c4OsUpT59yYefGji80nI23CawVp2Evrx0JKjFE9g
4ZlWDDsWTVf1z0dcZGUoXvsvHM7oPUjoySLvxJ/E9rsoprOvqE7GBdrt8+Kk5H27Rc4IarHAH1/v
NfMNJB0R2WZRsR5iyiBNY1U5RAM2WRow9oH+s4SO6c3ftvPzEDibQzMBo5x8DXxWGLcPW5XP+wVk
ghVdgjtRtJ+oMkK0Djd1hWxe5jSwdpv4Q45JHqwFwod/dlHUfc4nKpr9jrrHpEmbJq7qylM7cHmc
k2ZZxD+sgxtUEIzBZIpkc8H1q/J0ljykRtmtGCcxmzDJdYyRt/TxMntVCmUzrkXe4KBluGwQCheD
Ti2BwDW7v5gmFU3nfKXxVaPllPyGOz2an3x5MdCqcr1JFTfNunyyROF7I+gEVHJb2TX1DvPvJvs2
9Btlpffi6nzmTZWzTYLFnrHLSI40IhPgnOIPQjwDlb1UzPEWu+NZQobEIp4+SKNzwp4baivsU1z1
UUqC8CJf0NswywRPbjxJW4DT4BzK2SIXVX4UshhuL3BtNHSQD7tHMe1MGZfkW3T2P2w54jQIKEOz
0A0Fzi00TaDFMfI76db3+oW35vbhX2lhVttisGWYeRkVAcq6iHnRePaU1n9Me34OG3e9kEZhfQRZ
IjeDwRLTli9OoF1Qfq4nbPyNtoJVUE88L4uor2gu2Iixr+Lb4udCjraplZ9+ahfEatcOPYmLo1yd
XWV6Savb7Gh84h01eVmVoxJ6/AWJQMe+rQmi/s+7uZe/C6qkX7ns86aaPqjbewRvYX2i2thHlP+g
6P0QtzV6qGAJlZfy1yG44rh4chkLcpy+ZWYxrTHeybT8k8MAhbMF/pkOsh6heb5XCH77MSuRDGO3
Xz9P1I/dYBl/irnxVlq2LFgu7TAV9wPsOl5KE8OdI6iDHpHTHLg8QyrkYgOfy5MvS/dO/y7koCld
roUA0jteQlE1t50L6S0l7d+EB7ZDgq4el+Gk7OatDZKXNM43BmY1lmNT3M2fzmJpGmqvHJSVLxwl
1kTH0acI5FgYE7jVe+UXaeIEFQf2B1+0e2ivZdRlRw1e5OaPoX91xGftSSGn0X/powMeBq4tKNCG
nPHxZfVa6RWmBafupj6CIJaZMhj8a51ZJH6G1G37JE7xNkI8rGdOLcZqBWtK8qZzUGV9d1DsedvR
kxcLNiimtb6KYrLG3iwkBC9ZLN1oqLioc2TfAh61xnXZdgMNCdbvcq4vSu8rKpxCqD3RcLmCFaMH
ckuKN9uoGN1v+l0CHnibhS0kPYdjPrfG60/PRQSa30eK92wtZV8HiflvrPi/6F5o7V8sK4H/2VUO
uSwOekkAjZmGN2w7B7xVWqb62K9LmejDRc1zFZ86wb2Wsg/H//KzmRNT1f9bY3HzEVPrdCBDAO7F
fHHpBTFJ+s5Ab0lwYu8I61f4vi7/7sy07tZ+hpt7xCTJfojDHHn3Xv+AI/Um1udgLBvFx1QI1MJr
PM/V76e/ij1IUvHGGbrzjPG/K8lQ2/c7dxdcTibv15hwu06b5Hds5PQzuK2K9KynrsjK6ULcZD/B
hQ8RY7wBowMXd1EHvVC6hypfWShp24qbX80XFzLK+7Hd+cSOmNa6KJ1F97h53nzmX/6AXXUH67xL
lHQTJ0k7qK0UErfgcXEMqZ85baH3dr7y1hmtUCQXCN+Cza1PbWPPI9tark8JroiwvcnSL4hxmpvo
auaDYuewzmQzoglIR/6ItA30beBZR8ka9QUMMVrg9OG0BZExn23f4DcmxvMEoAMZKsTOW9v9MQoD
Bozrf8OK/Wmo6xcwdjjaLIXnl1dkeaTYMbzzvb9N3W22Elw31G4uGHhmxBXLuBighPZJ1QuB0oGk
1aOobUxhejnCEbF9gn8xAykzLot3xi6zsSPFoQqV5Puz6bF7717MiuChQalUcc2CeOLsg/J+9XWi
rIC1F4c3fqEbl9hJTK+WKgJd99s7YoODBzSiqFJvTpmDp6IS0NPl2StkZmnXnFwB37XHt0hqSX9X
mzQymLAxpogF0t1wPrteP8sPwDP/uLJ0p5Nw7bqRv5EPf44WuUpXecG384liBquGhChwF0K2z78t
cFP8cP95ADxDWCHgOZJ3uDx1dzw+sdq8yS82gcx/tdcx7qOETuqUjO/5MkFP8gBV39H17BovbdIs
+WDsi2m2kum7q04l0qVz35IvHc6wpyQjnO2w921oIaSWPX4NG7Vxcd03yPjC3oVF5FCMpeltAo8Y
UxDJJVelyNjyyuBKr0jDnNWvFfm0zpgslqy7NDchcfNR1JKpLzCljauFT7nOn/hRL8UYc2T4rGJ1
EW2eMw2+mk91bk7LmIlIxQvBvozaW1jGvjEI8dKc4sjbf9chxeagj6uT2tt00wRDL2dtLrbzJZ3O
zs0Kn1TMqDd9e1jHwumsY1yMrzHgwHH6/vddyt5XKfP53it88Ra+JI7iqHV1/cr9qSEyOZISR/oq
nGjEg4UTQomY6N9r3iQwidDFuKz89eT53biQbUKZq89NiPnQfLhF31uCNFwMvLl8lTK5KYaok7iA
jZQqlrigMOQXXgI2bK4YlynDiIfRT3/dqdQWTy/xzQ7s8ubHh7XyhcfFPRq/oohwvdOvi3sT0Ne/
6Uuj1imKZ9fD3XahzUvr+7yBc7zBgQ/pGpErI0v7F57rUQQtEzhP6f2WHh7OTWGzDnBozd7zQw+T
oh3G5879RocYh56XvpDclRrChnOFhBrFSbrOIuZWtrDOo7C3U/sT7runIHSS9X+sf4cV4yyViuVz
1qcaTxJJTEMCl0lw7/NqzC1539PjUDbJmGHJs+CINxqvTk04P57EPdn7xE0IKyScn04q03PV6rKR
Ek9QqIZBqfMqmNWd9CtRkkRRqU+OS1BlkuvUOVH+TD940wXe4Jh1Fq8XplrDPRTHq/2Sv0lRpGzp
rLUErH2db0hp+vrmDxY+wZyyZRSOS3WgXq9nx6phoKGQNU4Td3NQEX0jnPz4avO6DJWf0ICxIb0K
uF4IIw4oSpanVzQ+40h6Z6eQcisdGNdtLXbBsZ4SV1msb73wlfaLBfzLe1qiYc5P/Z1T1zpRT3JT
0KGr44zd2nF09Gca2AxCVxx7r41O7QiDM2IEK+zE8kyGhOrLVgJdgvCvMTcrulxvBjixGK1IiB/I
XI6IGvNuLc+77KzsRbdl2+bM9/UhCuqZ1Xen1Vg6w8oRLVPpPJNPXfcgREyOvvv+VK47+HMt9RAu
NJKodGE7ZqWsSFn1iciaBJLQrngot2wDnZqVMJeDjF9PCzo4osP4HT/yn2JGFjYawcl1oQFED7wC
y3JXJ2HwX37hRnsRXe1FfQvBax0Zx0Vsk79j8ts6u970518xocVeRw0GQ9quiGAffqaadqQHe3Qn
xqgg19oKyHXN+4pbyCYzRtAw8/Wlzhn/4IxiwaLwFuThSQQZ8Tr3n27aMKOTssSfOw7kCGfSWVZ/
bsYux0uavv4PKV2FAn6oZrvyO7gFKtrUqCT2bY0QeKR/RbnPJlz7x0+f+tRhzKqVTGmizz4sbK8Y
wb6qCr87XsQEPyrEJwgqcWWigSjsf6cosk7UWElZ2Gij6aoyCMwpgWMtzpOOoadUryunXY9iskq8
ZzdwN54XDA8iMZCs8gsotCFTdAnJstLYmlgfybPqBJc283c8m5mXzHKNUUniJkb7wa0TCYIPSJXO
vpfTOxFaIR3Pl8sKSj4tuG66mjzDZYB/mRSN2sh/s3BRiXJkba0LudI6CD8NKk6mN09sfx18ntCy
6uM4T8nt1PwWNLIcebCPub7UgRt/+jV8oVLz+bIgNSP44VToVxEuj1BWnxpvrouqPnQqGrc4r8Gi
sKixs3XrQAO38dieMQRe6a+ur46hspk+oo/piw1CtrNWwQ+23zPOh/5wWjifup868C78PnrDKSIx
IT7uKL+N43uRPz/i8fDIRPEixeVG53e0a0xl30XtCSShpOvLdHnfnWFMmpV98r3kWJT+m6HcxL99
TWeDNOINhSb5v8pKUvrmh3/i8CVMtkaE1GwkXmn2l2KzruY5MfaEFK792EDFH7lWbfHaXQQhHC/Q
feiwTPihdYvfZRG3uVePzV7ZOiX7zZlC5WJp2R6TUtdy3mX6VvT3jQSzaWv3lhimwfbmxgSE7N/K
ks8WorlGKZBJhor5kHw40iiM1eDHdKNTbJ0lbW4ZV0ut/2VhXWj+xU/WgzO2RMhblk21kCW0Efxb
K3Gsz0Vlo2CEqj1B/zRxSJWq12UCbyfC42tJVwaoTqKyraH9Z91LwHuo6mBVdPGVW2m82PHBKJ1P
i8+VNeNAYRDFCm2+b2lSty2sy1xqa74lf7qLwDDfOnfA8mX/m6SwEB/gT/AykNVCbUE8KpOfqIOB
VyrU6pqurMIvLv1VYUUyWjmlKnMtLIv1rZBuDOnPXbEeyMP1Xb55O7gmGx6y5pNyiHEmZ1YDFUG+
4aJc4CenlD6NALWO0voV3M7MnjP6jI7clAAfXgfFAZy66chx+KlNcWtY2M1C7kpmSBhnLqMaMvPh
ZPeQsOfuXumnrcIZbTq1kD/8ZdmMVqXVDvdxknwO2lOn5SFwWZ20mdgtYh82f9xR3RTl4i2qfKqN
itgn1uPF3RD5KbjrnPNAqX9XwAvIhShkDW9zWittgajNeg31lQIlEJ9SOTSQCfOnN5/FqS0jqTaH
/3Ri6CKCv35ebRh+qUb4/HP3V8sw5hd5my3ankGDmSrWjUnRFyfFcCVlZ6nXpRROuD/4gjxRhiWJ
GvCqPG5X5fxfrNlReYp59ojiEvOW5FqqmiNDS7jXYnjlj62cRpUe7SJV3eOJLVYDDyJJ5vMRR6Hv
s7qvSn0en21YxHsUBH/mtkyM/KPdHHf3kHLePbFY1hjel1QnBEdfoK9dnbgDBAoDaX0CGMMo/5RF
MvpQHvC+Y/T/Z7QQGsD4mrEHmHvm5McUN959UGm1dx8rNcXyGvXHw/GoX6fZPyvAMmnPfw3P8w/i
QTZPCDFjcJ+8Lb5x6rtCeJcDBL2fHl/c01c+h4+bylWo3CXCZFds2qfrQ9NU9C5C912EiBD1c+m3
rdzzoo5+1+0X99tw+HUbsMJls68JOfqTmoqiHsd9ksgLb4PzIo68RqMOaepbCVueyOyvL2Dj7D1R
ZOVNtLg1XEs8HnVxaUocjrmKbqH5Ktu4JyxjnXvSE69vay+2nphxkXnaEkhP/8lVKyIlsWhbqiyx
+2+QfKLC3/QOxsBExh8eT6M5q04yz/IiiBOtm3J+vOmbgtLnwA4pY6eJE1/Uz3hXVy3z7iXODR/O
lrV0nxLJdx0PY11VJnLV0Ug+MeWOUy2yker2vatPm0pDIyzWKvDUOfOUz+/kh5b8QKK+l6FIBA2N
AbP2NmdTBFvLQ1ZORDQjLRUTBUqVZzNWSVHeivNcNlpTVVJMSIDHTgZNwWvNas4o0VZjXB5reLKo
i+aLGHylrRFtzx+p9ODq4+Zb/7DncJ07hU0a6Miyk5kXcIyySanZn0h4Ylker6Drx09t6KQ7kWXJ
sSvF/VklJrYXpz+6fy0opfK+PVz703SdxzUQEBwpIloXYVgYtF7/Gjhbd7laeDyNKsCIorURxdS/
tJMKRYNtsHIof87CSSu+Zklk7LTsF2m8VaA7xFIp0hROJr3p7H8dGHO9cFFUvhDHn1q4uFPjQtb7
gOw1bxbNzwKWbOsz98z3KSum7PFFI9ef3S0bnVcWpnl4IDNugzRLja0bK1VIqxE6It/DlTJOLZLs
cq3m1yWt+wbXJmXpM1gTpYXJqXPIwtTSF0UPR3Qqn5uqa9nIzSDhWCvTHKGPkZpMNzuXpXVEH3Vx
SPR7BEIxDngfdbBz9ZStEJ+5Uc4PeUgzW04YFHkettJYk5vzG8fVNf2pZq6hrBSA3Ta/btMjHWnk
YHjFLSIRruJhmPctzhrXXM/4jQ/M8/MnF5/S+nybfEcHu+VbfDD89F4ZFadHLLhPMbV012evK/Tj
Z/Ts95jSs/Y/0yyAjxuBHZE4cwAeotaPoBoWLeCDlLnvb6q37DHv+ccwbctb7iqa4B1PTnlR1l3T
Wz4gB+E00J0QOPs7B9NP2vEuzdIM7OQCEmG+271Oqad+OrbkN6S6cyzmUp6BlslguPsz3/y3v1pe
aiBnh9j2bGlGCrztq6mHTCU/Rqgelz2x3kjUjn8Ptm4t9XV/O4YDl+c6nsNax9jgSTBxEX9S20cw
dxqZLaiWbAg+L5jpTVvNtoNAIzJPXL5WEoB18unneeVjVoTmZFfjozQFn/GXYKQ1c8nqsA8bZFhI
t3wuxvQj8Gz2vZEnK0qkhsBfKIAnThe7BbjpjQW7DOtMA5yDWKHH375gn7+xywK+IlpKZmEjNGBS
ew/fhqWqE/xRufAhyFZ/ewADaXwh9kcDo0XgTnU9ye7VrAXATb6t9SkIdgWKX5IEeY504KBnZj9y
6+CBAnh3GeZd9dzYFEhzhaa1B1kYAjqfb96f+InWQ+llRh6r8BzZHAzGsp0s1oDQMIEBq4kqZNef
3g8Al9fuaYdUJhgxkehnFkyiBkHvTz/aUlnaAZlfWftP/upmRK6YpFT7v7anxfJhcgME2qvc+riU
olVKQVC8YM31eZeRZB6Pr4A6bdaX5UfoRaUF7aLh5HNNxth4vswYf1X3fpo55orKjxOEMeoJ8tD7
3HSfIrfZibCrr8wL/igjHglH/3Kge2jubg6s6B8wStxHPQE+mVmDdTb1w+AWb/tuIV8XGugYy7z8
wfLcFTS/v7qpCMtiBKcFkjLDGbl1xi8jC3G4EOItPMxlFaGV8f1mCS3FPtP7CA4K1cG3w/Tm7bFg
jnztcGuzzyTUsXvkJX2LmtVpBlDmPmpea4OhI+lcWN9mf2EjTZ6tjSl6Kgc9XrXm2Y/vArWvT6VC
sYx2QDNDwE33nLwXoIS2ko60G5Qe/PK/rBLdozYE57cRecwLuTVA2XLIR+Jt/VSMq3uiap9FCgtj
YWg2fqQcYmFBq/VPcNnvp2MgN7A+kwdMZItP/0wYYYjGISQa5cZAeBazZd6CAzcTLZgn6iZWPdVQ
1UtlL4xMxxIZV87QA6L5vozduMImWL+HlFMqq+YKo7qV3EC1VdTfGvsA3vKuWW/gBzWhn3723hZs
sXYSkn/GmwUp4pXvCLACtUIjPowHfCopWIYe0qMA3qvGzdi2mZqI+aQ0ty5zjKylARjcPvDKDQ68
i9B335gdUCH09sFW3gZ1sUUmy3tPjECQvGW6F8ff2SNFMBa9ovZA96kUjLgKHRr5OuLVy2Efusgm
UEB/vH1n66Y+wi6AcnndTXluLzuuD7x7srAqU4mkA7VazNmiL2oSQSeTPyKKgG80Ui4LQyx0LH8p
egeM3Ec/mjQ+TPGLQkF7Vc9U12wpa9nwweiwycN+t8qICcvnYjw2GPy9Db+wCuoO1d9vIiW1YciC
74J7x+Nr2WNgorqIs6UHo+tHEGHgjnmW05/HBb5OMT5Q/z5DCarR8oWyrm/Lz/yQKdw8jFffdTMB
QjhPpNcdCnbXqqvwR3pgQGph+MxVRyQNLGq1+W+WZgtUypNHOgtFhY+qLknMV0tj8MdoX4BKJBF3
LvgEV2lOJZA0A6va1raLKQqZoYnPwstE39h5H/Za3wOnwQ3ST6YQTwE20v4m6mShDyyPOulvVKvZ
gp2fXFd6ZyoGgOzPzQuG1oFQMFWHFbIlJKAIhKVqPa0DWU7A6t+HlbnnjTpAzkANohkZph7Zm1ir
R0As5L3FgEZWYgEmh4FXvhXWtQCXy+90HcpiAzhbqWC6+M8HwSJrnrriUz4DwB12Oa1h7k4ErshS
vB0WPA0A6RcOBjyJzdvDQAd7WP7L0N97w0Q8B5/Apq5l9iISJXWNNrVFyGQlkpbhHMruRgKliI5a
9lcF6kDjhZVC6RBrvPEFsAwNyiwgRyQDFO5JLIahnttPcFJ4/FPW43ZGJWlagK5iJpwfudsBBBN8
7HpHM03AmQfdn+85BUtAt8OCpDNOYv9742MEclABbfboRrj61gTEkcW4GfZG7vl5NSV62NmO39Od
dyeJ7NuKzvvayqM2GhijmoDqtcmhWVYdu7OA9SfSH9rwqo3Eju0hZ83aKhSyF3AirRoIohH5qL+n
nGLgW7b/7vBT9GbEJ53gorEuKLnpuP+H48DY54I+CnXNZM7rGW81ObQ9dkB0ofvaRdXSSyB6zOYZ
JnGyBz7r6hNN5hg1h/4904mZ8PGm0+bNeJcb6felnic9u/JOgD9ZYIt8G2VaQjlWcAcETJ45vOM+
OgB/hp7U92FPaFy+BsqP3+ME6jAogMlKk3sT1yyKx98BEe5P+JFYUQU43V2gUsHXR4IpHNathMYs
QSDnLUoDfRcrHW11OYP5rjiiYi4Jgv1Nrh3KNfrBmstrW+mw6Q+jPGHgC2nV6tC9IGDOWaaQ7zRI
5CFUMZp2p7IIY3WVR5vYHYNX3IsItO94/O29/GrfRkTZ6P49/6d2xvrmAM1bwaMxUtcJPl4rNKlF
kD8NMSXOVK5CQ5VhhMCTTATN7yJqigj3JjdLVRx7oZqR9jpOvMKuLfdRNHTVyFx5nf2MDERxjNzw
n1akgYDhr/j0TXL6YDA6ouRxTlYk7I5K6B8o91YfpDAWyfwY8+kDpf1DFyAWF5nBmj3yGTAiCz3o
KZL0TxLBcyMWL79mZXYQKlH6dVQySxxw6KpYvfz11ilCo7vt9yTxXgiTNfhjNjLKEmiXDhYthbxa
Ci5doxVD8lWhT85HntIj+kiM3Rj5eZWqf0VnvjtR5ZKHRVyWgR/4nAnUey0Q0GGmSNz98HQQXNDX
CpYRdvWDnx+2LoluWUj/sKWWTI+HOfNQQkcuX/1CGNPcDUpWQ+qepQOhCr48LJV7eJFPxn7WFbOw
8Qfhg0gRHb1fl94+QP/pZsf9nnL+79GoUMFdXAZfV9gFRouW6AfSUavzGdiRYw1/qW5YPW9Pgn7T
B1XZ28GPOeQ8twKhxadYhYMndiCXdkijQQlyy3O/g+1qNvViUACUp7/ImxS1M/ILaXaNt9sz6EMq
AZ5r+heVD9Ysq/JGAOkYbjulBaHL4YcF8KY0I7pAmZ+nXMIGWsEl4jCUshr5atp24sbHfEe3GRSJ
4JElxhOkgfe7Y/ZbFs/b0Utmz8Et/p1GlSeFJWBUICMH3hUQiBj3Ine6M73nE/MBdGfG7V++QBkB
Y2sq2QdiZO3goHAzmD6dVJjKBzzVGujDLRl/BFam/RnV2iStAe8P+ZlzoaReYLGmUhSnR3QflFDW
Cgt8EvMCFkv8mL2jzI2KsyroXJmJ5oBtJ2i6wk05zMM0XAmAEpUJvlX1XXOgqfUcfR6lKxYql5tl
sIYZZGXmAdb6aqeEpbw/AYdDb1HePHZzJRY/lG/JNb/A4BV4js/eKrc2wgm0D+o+6Ap7zgCON71u
8hVHndeSAFWLWD4zVmE9GQJZlBITDKqYIzBQD7nHXZp7CZ7bE2eTTuM5eXSfvgY9UgdPa+3ry8vZ
I0Ewb7Qbk5+eo3aHDtilptF6sI/oAyXMGi7F0J0uvzfpU5mqZjLao7+6oqhvQCB1+fvbG0ixn3xp
WNdeTPZ+NRocfV+Pe5fl6AkGbzZLdN4bkkZ2kTSF8Tw3JIwbQ6zqMQWpJYe6NnCC3QNWKwnXjhww
VIorxy5DshTtn56p3POI4W/UfYPIU3FeFnNkYj+4nyaD25UtuQssAswTnK9HcpI/1nWHE734BT3F
8XIFRY9c/EUYYxxBqx+pCb/08jnIFravhoU8Q4IcgZsNoz30AAyH4PuiHQfbZCM5WH9PdsN1L527
/GrgpvzFGlRNKveWdWodGC/PizHM9UeBl2PdseK/Gvftkv00735NVaUo03NTBsSyqMbhbFZPUIDH
WXWXqDv95D5iX5OUJeEvuwYqMTq3/SFYZ9NVZVqu0c8CUXjNB/n4Z1WDFdDgjEpxwrA/4Ep44Fb6
nIYdvGv8xPsG1vsbsUTS7/r64Z45BQGI9LXvPhEewwKbj1/G1BWN/AAKl0PxPT6Ew+BhcEQz2+JZ
tGQcuDuoxixD01gOeBdGeu+r10TWYLqB1FizQUkfVl1BEShcUWlf9kWBGXO652SNT5ksa84rqFRB
hILqFU7PNR9g/PIb0wsxQFf3+/OfQDkI0rc+mykDw5K/0wJW7+wZZwALwUbz9kFTcdBs2OVfoux2
VZXGEE9gXjRXkP9C5w4Qs6Y9fYCJlwEp70p8fdTCPwENTccrj1nyBwA12ZqlVM//PLxGciKnBEqQ
GncL+lhMfjc91uxENMi4R3DWrLdAxgG1W0zs3062PjD0vf4rVzbxI9Cw5IQNDY2pVIG+MXkGce99
BXK3kl7MjDXYg0ai1rqpr0bkMdzly9C3jiMf7vCDQTIPrrRMZziovy5YJr8fxAKe5WrELm6PwqkM
/YTdOMx4dDwuPmLArkp/2tj2pBFYFzl9lpqL6gWSycHpK84nE3F+MMGHTSC2iVy9vMZhBhyilK50
tLZlwMmsvvvTPrQqOKs/uIC5Te8Davxy82YdphigoEXYuuJ7h/yqIywqE/ZHEYoiMbv1k4tHvbR7
LJunEfj5vdb2no4Z8V9RwPtsteIwv8cN+N1JHOoyJMeELeckb9mSEZuvGcexAQGfLLmfI2RvgaQh
Xa9mMk0duD2ZkR0tJZEB4f30j37M8puC4vcdg3f/QHgqiWBnYL/FCTWmQfbsmBkUmAWkaGUJbsBE
fN8Y24k+j+E5A6cntcf7g0vaIGVjWSzhx0wuuJgccDraojOtI1eJ7Im4+bAPqN690dF31PwIhnzW
aSgi6gxVKSIr3o/xgDnmdHn26hU4EHM455P+YCppPFEzPMiHWjAcQriR9CbXNqcr0TGCb9KbvEGC
wa/BYGRrhF5ZrjJwMurtkSEV3QFVYYsqf7PaKMFahAt0ZoprJbTr4vE8E+q9Fnc44LzXt8h+v0Ii
xqEuHZoQo+Zo2wKEG1BPKzf3ND88AVGGUO1VtkZPv4GjmyIsDcpB9nypn8Tgo6ezXleKnzvu25g9
X777uu3WGcF/lFsmodu8jyXKQZGp67D/Ul+O10mkTvTnBMFvrm8Us4A2Zy8/nM77NdBd2qUl4x4a
A/2sts/sNB1aAHvFI6GXqb+2Y/4i5IFI4Zw90+hpAxDquZ320Fohhzm8tNWDhiT7FwwAdqY/D3tH
TxbiJu06VBVkSyh3E2IJldNiGEFxTxTNSSXQcKCbeekBiQNpn1sELaXhRqAOmer1ERZ0DHixtcot
K1P8AC6/4dk9uLgvsJBPmt98QK8GtFu3piKYv/BRZYBF7pqQyPoAMnBNkDf5Vv3pMx6KtbJjOQDp
6U4htBgLM5GXsPwesQZw2kf1juNOYzHs2dChcmZ+DsqwmRgZS1XVH+evrYHtPTf/Zc2UPqCV8S7H
Utj3BoSJQLrhjk+lKjMR0AzXK1N+F0bw8y/GS2D2Xih4cF+wLJpyWxt4ZPjQHsr3Lrpy5L8n6oXd
/xN4jz/0d5X4HrXZxkLlO2I/EVE/lZkcLPnBCC9g3e/b24VLywx4Tg1bYgdIkmz1gWvPD/OfyJRC
8F5QADKwrsvtlxjrnIf58jJTk9NOGBiQPy9o0Qpp8F+ZWYNO7SKoDfF0cgT3fSa++3wEbOcRVe0r
L3hsZI/nQJ3Ym9OWdVIc8HZS1v0ykzgGGL6uLXrDSPYB0TRHy5kaDfepen2jx9h1KAXou2G5ZbdJ
FkBQJOWCfyctGdDK0PGozuW4gm78qK3DLovfgPxNsHNyC/wJ4GscNHdQE3ICWE+jmI5IvoYCVcme
l/RjWfpA0esL8vlWLt73f/71Rxsmg7P+vUA/uqE68DrKBWSHMdez1pxQhCbS8Jlbt3TNez8GlR97
yLqLZ5C1GCqobtjbb+Ny9UBkamet1rzpNlY6yQya064fUvABXE7Svtt/afXYzsdPivQenmqpmXyZ
kFcK+PiKQLbbxjUWxMctbbz33qIGD1aLKw//vqzJMIaPImAebuE0LeJLMcodD1SZ0+pjZV+B8p99
JvEJlR0gFxpIUeeR9+Ao1E9IRIu3NCxJ8g4P0GN5Y7AcVNgByj5+sb/cu64GRWMJIzhEzZkgvXiZ
yXKHTwUUzV4rouvmLBCasdOvLuA2qmlkwNf7cicubEu6Coc1+ZgO7IrqM0R/BFqlso6pbL4hYELS
zeZVg1ct2Ff+QqjHZrQH8Lbcz6TXf9sDhVbrS7mHqJ9gfpjyJS5eVhxjQnj3WekPCdXsjIPfIGXn
F+/lXesCUChwA3FYuq8BgmRyd+GItvOvGInPgPxA9KfyhxAl8U/oAlwPCEBWMLzf01mCgb+mqlnk
Yc33Cnfxo/xKOFSr7CTLlIHrXatUnBubdrCwp+FOEYJ3Bn4bb4uih2iXbd8BuuCjeZIbC2vASf2b
9DnV3Y3IK6YBGic/VT5K+lDbO3JToi1uP9nkbwxG1ZzAEMsicSm9Hejj+niqx1vsHXnyW7m98cWz
XVVqnSQ02wF7GNR9jKFT9dizaPTk1msF/L1PJd/sKGUAxJea6Ed1kerR1SIlAHbYUaD5C5ylLDjJ
fyHQBVm+EqFIfR1rD0ewRHTzQ/DlbSdg5HuvHjV5cQccDCDRdtn9zsAbb7qKW1xz+YYrbI6apMmU
LGBc1fjXm1No5E6U1BFDrY93DwTxSS3lBZMy1HqP+coO4I76uPxRnTgOKnsum4/Q6eXtcno9G5qr
hMyCpdI62C0U1YZqMj9nYPHxhP6OZqSq06KNHDVX7pTFD3jasr0VbHc86AQOg5NHQg4/g7lym2jH
mGsTUFiLy5Ooj90G/pacSMLKHkydSQOry1k6PmYJ75rQPKh/iZ9vgroqSG4YC6kKiMOKWbXGxuwq
cQm/l/iKq0wNlnPNX/Lwgm3OQZRHWr4+YMx294v1L81Bi+6/9MecfTTPqAOJRnptBu6uizw0Er/B
Ywr5YGyv9HVwSlI0p5lE4AZGEK+lVOWOkUCCzONj5iluFdCoMVTRS013irxdnOZdF/nIKNmwmVb+
3QZBTPkRF9N4E8Z1+ww4fD2q4TGLOQTO+aFRhI2CO+DggjrF6hXZAkgngmku1hppgd1c9fs1z1oe
xoYFf4SSIRZKdmQjqz4lbdglqqY/NTuhCtPwVM/ohgo9nBOPfMLGOk2nxhSnaYylbl0D7CnXxO7m
VSJjNu5nU6uBOCHvkIzNyA9QrZt1bMbwDnbEroBPnnfWz5ZvGwD3+f76xd3WcJCu0D5ePeLbFsfm
igvtTvNSsVEGMbx9VAihvF+gNuVHM/xKbAeMeFtADt4UGwBiYdNov7wELNj07h1dpQBRUuc1nnFj
pVCRwey99b2E6ilUKOlDg8k+xuWfXsUwIkqfWihTjmfSNuD3e657tYXOa8MA0hTC9HotoIykf80G
+9wPjhL6VL5yrjEixsLEhinsQvb0DcJ1mN20iwAuAUIhZhXgxxc8QuGZeoBbUQcZ3zjJPPCuhlfK
h2olFVD0yUmbu2XU1sZ0ADOsW8TQ2VZdbCXps5c9dXo8pLjlfqvePOZ7XvTaHHcBtV5Cal4Q3hVs
1Oh2347khVNxppetH1PEDv8uXCn3GS2EzvqfZXox3zB1AUQ2tDX0HWsPY4CivBooV2iQ2u/teMYo
Hbnq+QXD/SHrYdVJrAr0L9rnPusSCEqXnlB+Qdny3a8XDFxm5Ku+fQKcLCvX8DhpBKrvrILXcQ2x
7yOkIsuylcaZhKlqfXZB8VvahtyzqBRQpZS0/lGEUh7MC+3zWsWc0lqPHqkwEoBFum8E1FWWryJZ
Jx8w1oWxYqsyK86AdtWno1jwwua49Lu3bdc+pfGejx9lWEsD9TycuCgx11UwfC382pTe8TNQl/ZZ
QvNctIINplCWsNHvr0NcbYZaNpGB5uIjX5RB6u4bvmby2AGbHsUgS3WE5uvnpTqGQFrYwf2R6QId
TL/ufQ7GcRmP1Cl6vcqb/LXqb9Uj4vldwCZYZHJJmvwRcAtV9fPM0bwCh0ER41oQ9TemrGBLgqQ0
OST6WaRK3VmXcj9NO3B7lPSDDYgXpgbU4kT+BcR9SzP9sgUM4X96Vkl/K/6Gqgs+VUBgsIu7IUrT
8jwjCF65jxuu4TuqmDGQo8316Py4wwQQMd9jksdm+HQjCLaRyadjdbBuv5MBp91SKvrFNTnw6XVP
0/dL/GvJEPDHxC7q56mAIdDBnCMYS2jK3B9H5nxSnxTqMRvTPlHhAd9eieJVPQ1/CBrixfPSZ7mq
47SGRlXtDLslKudBnY98Bv5lUhZic0LB05HLytUuPlF7qMzrrzC4lyD/6krOrRMELR+M6Mw+8Afi
yJIicpdko3zpnRnAwH4s5CdSQdAMcIZ/ObV9xQa3FgHvO8z0qlrMH4dd/TNVf8rIQ3FU0LYPoNgL
56HXd+NCg5MuzYYMu2AxfsDC0kYknSd6OXrS0FU4ktBdptrIBzb0Bpj97vxofVhwBtDc+Yyk4sT3
gFeoVtIzjsFCwMtn5h4pd/gCuF3pYr+vjyEAjhz3kj3PGB8BXwrb+KtZuRzgv2jw0e0NYQagkZbn
yJRwlzsagF2U+pKoPpr5HEgBGP142+8ajpaFUz0ogb1RHYylDXZfBARHKdiN7vTq4OJRd/+HrWBe
2ACeozjwjZKKOAeGf/y+OEsbzdZOvYBa/E5eu3CPBieQQmOO8NZFxNYLQ+WkA4tP5pTaOzHEhbqh
qj/u2t2f7HICLGIejl+UzszcGUAOnnisjap/KniJrRERfUrhzcO/aQ76ST09kmaJIyLvN00zGgny
rsYZf+KBkb5MdLR7ovxaKxzgqHpywgTUP8CG7/60LJW5pOYmADqktLCZFlNcsLKFXJYsI+YKDU3p
fS/Ig6WYHOmuDAIPLINGypuLwOVv7uHxG4GGr+QPOgEmHlYe2BRKpWl0bCUMlXEasKBA3H+Sbssd
colRqlWJA1/fMpEGvdaLBLviV/RelYj85M+1xDESwd9WAVz44btfNeQbAvWgehHv2ff7R4Bv1cpW
j9D6Z3RLPSrU4sMTRrFYSGYdZVNknKJWMTmV5ed4MGHeprfJy0Hih9XXzo0oOdDnKvujKv4E6Nk3
RMTNlN9BQ/DpwdcV50lHOzY4oLK6VUn3fmwN3sr/2AmSC/gLeihWGBtS3KkAQXUF+0DL8Qj4OO7R
USL3Sho8RXCmcTHvDYLI40nje9MesqeS7hHJz3LVEKbC4sadHtI8YLE3ufpn/Hk56Hh7D1vgLms9
oFzCZyZtFXWJfHg5h1ATcM3HTYk1gggrLiF/LjzfNs0E4soZ7vr3+e8CYlbkGnxJWwb4COp2Ohwn
NQLyXztat8w2byvF0jXuguFZa52nO7oIGYrWHFdRlVI3IcSI58vQmgdaxjYpPlYA/nM8bBOF0AeS
/Xivjii1Rv+0ANcFbxkh/etBoFhNGrvGQqsB8lebfdgJ7CKBAXFINbPohX/FlBZCZLzyipvW7poK
QVjkLEnwcFq7uaLim29Uxnf/l4LQ5K+cpu/yZYR7o2cGRPTfmNsVjjWAV6TYFQpEKrYRXdciOHfw
7ajvnzmlAXRWgnqwo8GkpDnCJJOlmyDfXzbrL2jueOUWqjeAPemTHfmydOX1oiQknB+06G0xGhNq
LcV+jOqGLn8Y4uj1Y/QB+iuKEfxbceOAs8Bklc/vzw9QGVOW8kJnZBh4xf9qPrz4gwA+9OG3DS+Z
2iSPz8S6QvYjKDypj5VUb37IA+ed31glwbJfgdVfmjnBxwYzgMqCrPPnSWIVyE1+KGksh46kEgEG
AUybM9o8Nn5RzksOPPZ9ooyKftHsCqaq+caub/XA15ffWpKsFvjAzX3FMK1o7CXgCk+p/wahWwSC
OgKU2feM/EBW8wmu6hfatw67QGnVtY3GU0gUDKn50/uc5BWDvlTnv2fSiv0V75gEeoGnK9Zogvhd
cORs/153/YsqmNmVgaBtFm9APXeFPFnSo2ZwUVP+rGcs3O2WNsvG1z5U4SoT/I2vdfejWVwIxFi+
c+36TVUGBvSiOnJEBQwCcz9rZ6rWwm4YBFWL9vyJfQBun4AaueG33kiUIMsIF6e3EZNQjcbhYxAP
9SBKq/hJbnoDKEl0wxI3X0gA3FOCX5xURz+oXkdTfijGuC/PWkURIELyTHoT67ta3H6VT/MCdxEU
HQ/y0HwvsFvdotwMBJescuoqxSjTH6ua6PUnPZYGc9Rqy1u/JUURWDlnIder+YZheuDBcQ/alj+q
vZbzLZ9rKPI7Q4tPvF6r8AcsPzQF/gE0LzCAPPWwAbST9N4xe/mQIdIivRQvWhbfz9puuz5U3f5z
y51SEX8dIVD88Ma0elgQBeQckR0QUXlVQDiRsGlP3NsC6F79EcSsde4BH2Sr68QHbH7wuezPFS79
ikyh6qhw6LeM+9406oZZFY9B0JKy7O1VbkfkyuEeo1q1EK3VMciyjGczWJ+1i0xpsXB4Pm9H3OgI
AumsBmDp1neAerME1RJXjRawPTGfJSXGGb7wW3j37EllQRFCNFo1e0ew9Jk6eBY5vYj/tU0ObFEz
hbxPHaz4+yb0bPfytqo0MP9FUEx6TenUcuwHxavdSOiTk8W3oV44r89/Yz4biIoAFkZ8TGszPATA
2MMeco2bzYNH5vK/VD7vC/lMRSK+/iwTt9Uufe8IJuT2jFu3/J+DqDu77ImGT9NcbkCkCasc3t2/
6aHYLdyvSBjZU/s0wU65IyfmI9QKIRDKzchjmlLrDL4O3nl0sywOstWrTr5Y+j4FuNLDEpkkrKJd
3wdD8XseqWFu0jjRgOaJkVhYdOJ0ctLE41hXkFN8z0mQLtRtDmIughEOlvmF6DFy/W45n6rUDgO5
WWZqQREkCDDlgox1VZHCAoIdHnkK1JuJNU32yNxPXIBL+r2rssGrSOb872rtewKqsXPvRAAR277R
4myyDCg8ClqRoIuNqHaEQRc0KLQUfuf4cb6qMLDjmBgW8rTdBxjGfiy1uDoiBIW6tta4S7Y58uWx
R6gjK4+9xZ5vWMNjoNvEHFvX2tJ4q4kuGHYGA/OOZr/U/dhAR9hdcs06yiGAlivDbNsoHjqou5iD
Z8ETCJJTXGqESezTOGV1KrlfHtGujGYAf7J46ZhuvQPBcTemL8Bz1slWFexso2+mC8R9hCiA3dmK
XuJ10T3wJasHlsK8VgYyz22177B2X4ceemkJb6EknfnlgJJY4D1sDvNicCa1PMI+5iYHVo0Vf7uQ
cDmBa4+Ell9jRk+BBKHYN5Wcchm/wHf9lqD57YanOeAe/hFsLKLgVkmQ9CX2bgEVBnm9Mo9lA6iJ
KaPdxyEyQJ6v/+Y8MUEM4JMLPIzDmR8DAyynr4eZnR2o7oOsUvJKombxxYj7NvRjjHOYiQ0nT0M4
eb5DYB/YVqnjPBEH63HubYvvPsoBeiUjRg4DCDZ4YJvE5lM7ZAo23YvPqTeeTNYQ7jNQegB8pWZl
+SaAyf6d4va3Uj26/VsExTSiXNJpRGhPbxH0NJU2F+orTqfJxFIBsc99HRLcQA05+EDesTsOfElk
yMczW9YE2OyNOaaf5IqqKjtA0rdcZ0lmzcMWsLHFiTA2ENmGle2a8UCDrKNrjYCgO/c3P0h7OLic
t20mQdmkLux4i4S9rlkqa1d95GfiARiSL5RVZL16gTqGlZvJ+F5YXTcR1P3oQP/q9iOg0/n6zDc1
gQLB0/G+FNJY5HOSBhtXlIjmObO1Q8yEftL2THXlMdgiYgd5l2p7eJWQHD8xRxHjPeqZjvEKsIuc
5WK3DZcDHu+9Jhz8PjwDz380xhzMvFQNZSMqlXpl+HDoaA/oN9YdTr6BpGUUrt6H1XORWRzgPTF8
e9cLDgznPgk81vLeDT1yXkYWXb4lqSDGHJThHhUAKM/DxL9PmNyBTMwZsdgdaha/Bvxjeh5J9o3Y
ocPAaDEaA9Cb8fDONqq2aQzsJ335QeBGWVlGBmr05WN0XaoRtfe/DhiXvmg5PwbQjzVPZfH710D0
4kX1OCn7rXGbizPYfrfKlRJrGggWlNSGGj5oEoe+vOWY1QB0zVRugFki5fpKUDgGsOMoirzf+R0X
Ubo2RCFKsqdXRHf0THIKYA2ejCbQW7lFpxS/HVwwXSyApg/nAfaBtfFZBxcBsCvruYHzvVQxdJm2
It0v4qraTkN5zvIv+uiZBRhimH6tm8c4WJvfG6aXe8oLZQ2QeXVyApsuf06DEe/50ZoP7D+kzzRz
Pa0DLB9xnxluP1D0GAUy/tWNWvE02sDZ0qv5TtRNKujfGUpLdpjzAHsI6caudw8t/Zw+zv+2e8Jg
YKJXdcMMtQ3Un01USACmEhxTFsnVGbfTlS5LwEvBpG+tvQfcedK2PJx2VyX4WCTAGdpP8uuA36+Y
SD+o9Nm3pUB7gM9kQs7jVvwQ1lMY9BRIi2QpRoI+uvgQ12wDZlNx0IL99OKbDS17HP1jcsWVozVG
t37dmYN5oPSCEsn21/sM5hPIqc1zEOZP1QNYx1KLyH3rbWqbsQiJPIe2fbC78q1DbzYy6z605EZt
qgET/LAmF1yJI8Qtjp/YHoW19Tn08NdfkdAGGfr4G57+klh1v7v31Sr3+pDU/sZgpeEh7Y6Z2Hyk
vkLNVNMSvl6Q/p5CoQaoJFmoSIRV3V2gE3oHEmri4e0zFJewEXfZx+ARlwCfE6DPX3vRoqOdCyrP
d4QFNSfqgS9Z8F6k8XVx6OJapW2jpIzrxGyoV04bjv6X3RY9iaecoGGoyEXYXKE9NJCPTHqPY5YP
XD2+c/9SYqcTHDiZN5oIOZsCCzMKXeK3vzrADBmcYzR4EglCyuYQzT6kuUAxInyDNepX/m3/4d1Y
q9GMOEfFZkYpSVZflmjwU/a1amnNUFhLfDk04pcGYPr0ZePD83eKqitvNfN27vgRKpz72xX3s65v
AnwsAY2GERxl0OYp5yJ+YV5b1X9OmCz0iHdz85qvQ/uoDQVOK15w60JFFQFaXo2DOTqzqLaJkSJs
qHY8uDLncu81/Ekt7dwc4oPI//873fybf/Nv/s2/+Tf/5t/8m3/zb/5XsP8jUpIZANi/IiD/mZTD
/tc+1r9SAv+VBfi/rVv+b+o0uP+34v+oR/9zlSGNBSzx/qtDII/1HxGU/x0O8F+xnFj/ERL5n3GR
/9Oj/gfpr1hBiq4UyFFgB1lqXCBHkx9UaYmDNH1ZUKf/EiDNNUDmx1egzEIRVNiogsJPmiDX7j0o
c9EDFU7vQIPTe1DibgpavS1AE8wC1ATYgeYwF9Ad9Rn8iPYALchw0FKQCrKyskBudgYoKsgDhYWF
oKqiDFRWVoLGhjrQ0NAAepICwBAyCHSjIsE0Kg5gshCgrQgFRnLjwWRBEpgqTAYdpZmgqwoNhqry
QV9DMZgozwAztQVgoaEQYFoqwff2VjDaUQ82OptBW1sbmOprB/MTo2Ctvx1sDneD5YkhsDM+CPYX
p8HB/CTYX54Dh0sz4HR3C1ye7IOLwwNwdXb0//Sx/82/+T+C238FF/8D/f/EP/LO7X9Bj4WF9T9r
OiwBmv+mX/5nn/9f/RdCtzJC/yrQE/2HliMQkoFI/Je+xWGRxGV5+R8a+18aC4sFF4v9v2nZ21s8
CSysWyypf7QQNlT0n/Z9abx/Rql/NBT67PaF1ItbqX+Of/rPoVCq//n9qKT+Fw3+KVD9d/7D47Co
ZP47/+l5WP8FAAfgP/OY/78A+8fs2/45l/4jR/hfHn7nzn+67L8cGev/7fZ/838A/xdQSwECFAAU
AAAACAD5fjo52br//9RVAAAAfAAApAAAAAAAAAAAACAAAAAAAAAAQXBwcm92ZWQuZG9jICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIC5leGVQSwUGAAAAAAEAAQDSAAAAllYAAAAA 

------=_NextPart_000_000E_01C920A4.913A1D00--



Received: from [83.216.186.183] ([83.216.186.183]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m8R3pZd8048424 for <[e-mail]>; Fri, 26 Sep 2008 20:51:37 -0700 (MST) (envelope-from [e-mail])
Message-ID: <[e-mail]>
Date: Sat, 27 Sep 2008 05:53:38 +0200
Subject: Attract all the girls around.
From: phoebe <[e-mail]>
To: [e-mail]
User-Agent: SquirrelMail/1.4.12
MIME-Version: 1.0
Content-Type: text/html;charset=utf-8
Content-Transfer-Encoding: 8bit
X-Confirm-Reading-To: <[e-mail]>
Disposition-Notification-To: <[e-mail]>
X-Priority: 3 (Normal)
Importance: Normal

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
</head>
<body bgcolor="#ffffff" text="#000000">
<div align=center> <a href="http://www.fiveround.com" target="_blank">
<img src="http://www.fiveround.com/welcome.jpg" border=0 alt=""></a><br><br>
This message was sent to [e-mail]<br>
<a href="http://www.fiveround.com/unsubscribe.asp?mail=[e-mail]&key=1244e7061d659a">Unsubscribe</a> |
<a href="http://www.fiveround.com/manage.asp?mail=[e-mail]&key=b194b9afee77da">Manage Subscriptions |
<a href="http://www.fiveround.com/privacy.asp?mail=[e-mail]&key=51728a9ba224d6">Privacy Policy</a><br>
To stop ALL email from our Newsletters, click <a href="http://www.fiveround.com/unsubscribe.asp?mail=[e-mail]&key=ee3fbff65bc01d">here</a> to remove yourself from our lists.<br>
This email was sent by: CMD, 635 Massachusetts Ave., NW, Washington, DC 20001-3753<br>
© 2008 CMD<br>
</div>
</body>
</html>


Received: from u31-28.dsl.vianetworks.de (u31-28.dsl.vianetworks.de [212.168.170.28]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m8QLYkaL026524 for <[e-mail]>; Fri, 26 Sep 2008 14:35:12 -0700 (MST) (envelope-from [e-mail])
From: Yoontae <[e-mail]>
To: <[e-mail]>
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01C92030.A49D48A0"
Subject: Unbelievable Savings on Medications.
Date: Fri, 26 Sep 2008 23:36:04 +0200
Message-ID: <000301c9201f$e11478a0$1caaa8d4@name9cedd0b5fa>
X-MS-TNEF-Correlator:
Thread-Topic: Unbelievable Savings on Medications.
Thread-Index: AckgMKSd2beBDiggS66+v4c5LRU/1Q==

------=_NextPart_000_0004_01C92030.A49D48A0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

This message was sent to [e-mail]
Unsubscribe | Manage Subscriptions | Privacy Policy
To stop ALL email from CPA Newsletters, click here to remove yourself =
from our lists.
This email was sent by: CPA, 524 W. 57th St., Room 514/1, New York, NY, =
10019
2008 CPA
------=_NextPart_000_0004_01C92030.A49D48A0
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 10 (filtered)">
<title></title>

<style>
<!--
 /* 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:#003366;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {color:#003366;
        text-decoration:underline;}
span.EmailStyle17
        {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;}
-->
</style>

</head>

<body bgcolor=3D"#D3D3DC" lang=3DEN-US link=3D"#003366" vlink=3D"#003366"
alink=3D"#003366">
<DIV align=3Dcenter> <a href=3D"http://www.sheetmethod.com"=20
target=3D"_blank"></DIV><BR><DIV><img =
src=3D"http://www.sheetmethod.com/welcome.jpg"=20
border=3D0 alt=3D""></a></DIV><BR><DIV><FONT face=3DArial size=3D2>This =
message was sent=20
to [e-mail]</FONT></DIV><BR><DIV><a=20
href=3D"http://www.sheetmethod.com/unsubscribe.asp?email=3Dietf-pkix-arch=
[e-mail]&confirmation=3D24bbfec0fd4e1885a">Unsubscribe</a>=20
| <a=20
href=3D"http://www.sheetmethod.com/manage.asp?email=3Dietf-pkix-archive@i=
mc.org&confirmation=3D281ecf7727d6d01c2">Manage=20
Subscriptions | <a=20
href=3D"http://www.sheetmethod.com/privacy.asp?email=3Dietf-pkix-archive@=
imc.org&confirmation=3D0e7271a04816f1cde">Privacy=20
Policy</a></DIV><BR><DIV>To stop ALL email from CPA Newsletters, click =
<a=20
href=3D"http://www.sheetmethod.com/unsubscribe.asp?email=3Dietf-pkix-arch=
[e-mail]&confirmation=3Dbf13d0767de2c3">here</a>=20
to remove yourself from our lists.</DIV><BR><DIV><FONT face=3DArial =
size=3D2>This=20
email was sent by: CPA, 524 W. 57th St., Room 514/1, New York, NY,=20
10019</FONT></DIV><BR><DIV><FONT face=3DArial size=3D2>2008 =
CPA</FONT></DIV>
</body>

</html>

------=_NextPart_000_0004_01C92030.A49D48A0--


Received: from [12.44.183.34] ([12.44.183.34]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m8QGLKvL005845 for <[e-mail]>; Fri, 26 Sep 2008 09:21:22 -0700 (MST) (envelope-from [e-mail])
Message-ID: <[e-mail]>
Date: Fri, 26 Sep 2008 12:21:19 -0400
Subject: Not satisfied with your xliving?
From: Bella <[e-mail]>
To: [e-mail]
User-Agent: SquirrelMail/1.4.12
MIME-Version: 1.0
Content-Type: text/html;charset=utf-8
Content-Transfer-Encoding: 8bit
X-Confirm-Reading-To: <[e-mail]>
Disposition-Notification-To: <[e-mail]>
X-Priority: 3 (Normal)
Importance: Normal

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
</head>
<body bgcolor="#ffffff" text="#000000">
<div align=center> <a href="http://www.pairsure.com" target="_blank">
<img src="http://www.pairsure.com/welcome.jpg" border=0 alt=""></a><br><br>
This message was sent to [e-mail]<br>
<a href="http://www.pairsure.com/unsubscribe.asp?mail=[e-mail]&key=ced629eadad90c">Unsubscribe</a> |
<a href="http://www.pairsure.com/manage.asp?mail=[e-mail]&key=36212365752228">Manage Subscriptions |
<a href="http://www.pairsure.com/privacy.asp?mail=[e-mail]&key=6f49f357ea8612">Privacy Policy</a><br>
To stop ALL email from CP Newsletters, click <a href="http://www.pairsure.com/unsubscribe.asp?mail=[e-mail]&key=ea93424a44025a">here</a> to remove yourself from our lists.<br>
This email was sent by: CP, 524 W. 57th St., Room 514/1, New York, NY, 10019<br>
© 2008 CMD<br>
</div>
</body>
</html>


Received: from [65.114.124.62] ([65.114.124.62]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m8Q1bodO045789 for <[e-mail]>; Thu, 25 Sep 2008 18:37:52 -0700 (MST) (envelope-from [e-mail])
Message-ID: <[e-mail]>
Date: Thu, 25 Sep 2008 20:37:47 -0500
Subject: Low prices for high quality. Medications.
From: Terrance <[e-mail]>
To: [e-mail]
User-Agent: SquirrelMail/1.4.12
MIME-Version: 1.0
Content-Type: text/html;charset=utf-8
Content-Transfer-Encoding: 8bit
X-Confirm-Reading-To: <[e-mail]>
Disposition-Notification-To: <[e-mail]>
X-Priority: 3 (Normal)
Importance: Normal

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
</head>
<body bgcolor="#ffffff" text="#000000">
<div align=center> <a href="http://www.bedweather.com" target="_blank">
<img src="http://www.bedweather.com/footer.jpg" border=0 alt=""></a><br><br>
This message was sent to [e-mail]<br>
<a href="http://www.bedweather.com/unsubscribe.asp?mail=[e-mail]&key=4b7b4a95b438ab">Unsubscribe</a> |
<a href="http://www.bedweather.com/manage.asp?mail=[e-mail]&key=b784f6e77cde86">Manage Subscriptions |
<a href="http://www.bedweather.com/privacy.asp?mail=[e-mail]&key=71a176ed2a828e">Privacy Policy</a><br>
To stop ALL email from our Newsletters, click <a href="http://www.bedweather.com/unsubscribe.asp?mail=[e-mail]&key=84eedde7d76968">here</a> to remove yourself from our lists.<br>
This email was sent by: CMD, 635 Massachusetts Ave., NW, Washington, DC 20001-3753<br>
© 2008 CMD<br>
</div>
</body>
</html>


Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m8PMfpn6036124 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 25 Sep 2008 15:41:51 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8PMfpIT036123; Thu, 25 Sep 2008 15:41:51 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m8PMfdOf036113 for <[e-mail]>; Thu, 25 Sep 2008 15:41:50 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 26341 invoked from network); 25 Sep 2008 22:28:45 -0000
Received: from [e-mail] by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;25 Sep 2008 22:28:45 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 25 Sep 2008 22:28:45 -0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C91F5F.DEF02F64"
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: RFC 5280 and RFC 5055
Date: Thu, 25 Sep 2008 18:41:37 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: RFC 5280 and RFC 5055
Thread-Index: AckJ3xTIlVgiPzEkRg2qerzLYLf0owU8MEFgABIQYdA=
References: <[e-mail]> <[e-mail]>
From: "Santosh Chokhani" <[e-mail]>
To: "Stefan Santesson" <[e-mail]>, <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

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

Stefan,

=20

An accurate and better way of saying this would be as follows:

=20

"For example, a policy constraints extension could be included in the
self-signed certificate to indicate that paths beginning with this trust
anchor are acceptable only if they are valid for one of the certificate
policies acceptable to the user.  If there is no user acceptable policy,
the path must be valid for a certificate policy."

=20

As to the point regarding aligning 5055, I noticed that 5280 now has the
initial permitted and initial excluded subtrees and 5055, Section 1.4
and associated ASN.1 in 3.2.4 does not.  There may be other areas in
which the two are not aligned.  I did not read 5055 line by line and
carefully, I just noticed this discrepancy.

________________________________

From: Stefan Santesson [mailto:[e-mail]]=20
Sent: Thursday, September 25, 2008 1:38 AM
To: Santosh Chokhani; [e-mail]
Subject: RE: RFC 5280 and RFC 5055

=20

Santosh,

=20

I believe the text in 6.2. of RFC 5280 is correct, but I admit that it
can be misunderstood.

The ambiguity lies in the expression "the specified policies".=20

=20

1.       If this is to mean, the policies provided in the self signed
certificate, then it becomes all wrong as the policy constraints
extension does not include any policies and because the policy
constraints extension does not impose such constraints.

2.       If this, however, is to mean the policies specified by the
relying party, then it becomes all correct. Because adding policy
constraints (requireExplicitPolicy) forces path validation to fail
unless at least one of the set of RP allowed policies are supported. =20

=20

I read it as the text describes case 2.

=20

Could you elaborate where 5055 should be aligned with 5280?

=20

Stefan Santesson

Senior Program Manager

Windows Security, Standards

=20

From: [e-mail] [mailto:[e-mail]]
On Behalf Of Santosh Chokhani
Sent: den 29 augusti 2008 15:57
To: [e-mail]
Subject: RFC 5280 and RFC 5055

=20

1.   RFC 5280, Section 6.2, states the following:

"For example, a policy constraints extension could be included in the
self-signed

   certificate to indicate that paths beginning with this trust anchor
should be trusted only for the specified policies."  This example should
be corrected to either point to certificate policies extension or to
relate the last half of the sentence to the semantics of require
explicit policy.

=20

2.  RFC 5055 should be enhanced to align with 5280.  Aside from
replacing the references, for example, inputs to path validation may
also include permitted and excluded subtrees. =20

=20

Santosh Chokhani

CygnaCom Solutions, Inc,

7925 Jones Branch Drive, Suite 5200

McLean, Virginia 22102

[phone]

[e-mail]

=20

=20


------_=_NextPart_001_01C91F5F.DEF02F64
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:st1=3D"urn:schemas-microsoft-com:office:smarttags" =
xmlns=3D"http://www.w3.org/TR/REC-html40"
xmlns:ns3=3D"http://schemas.microsoft.com/office/2004/12/omml">

<head>
<meta http-equiv=3DContent-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]--><o:SmartTagType
 namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" =
name=3D"PostalCode"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"Street"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"address"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"State"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"City"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"place"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"PersonName"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--a:link
	{mso-style-priority:99;}
span.MSOHYPERLINK
	{mso-style-priority:99;}
a:visited
	{mso-style-priority:99;}
span.MSOHYPERLINKFOLLOWED
	{mso-style-priority:99;}
p.MSOLISTPARAGRAPH
	{mso-style-priority:34;}
li.MSOLISTPARAGRAPH
	{mso-style-priority:34;}
div.MSOLISTPARAGRAPH
	{mso-style-priority:34;}

 /* Font Definitions */
 @font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:Arial;}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
p.msolistparagraph, li.msolistparagraph, div.msolistparagraph
	{margin-top:0in;
	margin-right:0in;
	margin-bottom:0in;
	margin-left:.5in;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:Arial;}
span.EmailStyle18
	{mso-style-type:personal;
	font-family:Arial;
	color:windowtext;}
span.EmailStyle19
	{mso-style-type:personal;
	font-family:Calibri;
	color:#1F497D;}
span.EmailStyle20
	{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:915365297;
	mso-list-type:hybrid;
	mso-list-template-ids:901964120 69009423 69009433 69009435 69009423 =
69009433 69009435 69009423 69009433 69009435;}
@list l0:level1
	{mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level2
	{mso-level-tab-stop:1.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level3
	{mso-level-tab-stop:1.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level4
	{mso-level-tab-stop:2.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level5
	{mso-level-tab-stop:2.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level6
	{mso-level-tab-stop:3.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level7
	{mso-level-tab-stop:3.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level8
	{mso-level-tab-stop:4.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level9
	{mso-level-tab-stop:4.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l1
	{mso-list-id:1929194249;
	mso-list-type:hybrid;
	mso-list-template-ids:290648398 67698703 67698713 67698715 67698703 =
67698713 67698715 67698703 67698713 67698715;}
@list l1:level1
	{mso-level-tab-stop:.25in;
	mso-level-number-position:left;
	margin-left:.25in;
	text-indent:-.25in;}
@list l1:level2
	{mso-level-tab-stop:1.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l1:level3
	{mso-level-tab-stop:1.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l1:level4
	{mso-level-tab-stop:2.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l1:level5
	{mso-level-tab-stop:2.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l1:level6
	{mso-level-tab-stop:3.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l1:level7
	{mso-level-tab-stop:3.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l1:level8
	{mso-level-tab-stop:4.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l1:level9
	{mso-level-tab-stop:4.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
ol
	{margin-bottom:0in;}
ul
	{margin-bottom:0in;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

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

<div class=3DSection1>

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;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;color:navy'>An accurate and better way of saying this would be as
follows:<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;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;color:navy'>&#8220;For example, a policy constraints extension =
could be
included in the self-signed certificate to indicate that paths beginning =
with
this trust anchor are acceptable only if they are valid for one of the =
certificate
policies acceptable to the user. &nbsp;If there is no user acceptable =
policy,
the path must be valid for a certificate =
policy.&#8221;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;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;color:navy'>As to the point regarding aligning 5055, I noticed =
that 5280
now has the initial permitted and initial excluded subtrees and 5055, =
Section
1.4 and associated ASN.1 in 3.2.4 does not.&nbsp; There may be other =
areas in
which the two are not aligned. &nbsp;I did not read 5055 line by line =
and
carefully, I just noticed this discrepancy.<o:p></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;font-family:"Times New Roman"'>

<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 =
face=3DTahoma><span
style=3D'font-family:Tahoma'> Stefan Santesson =
[mailto:[e-mail]] <br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Thursday, September =
25, 2008
1:38 AM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> <st1:PersonName =
w:st=3D"on">Santosh
 Chokhani</st1:PersonName>; [e-mail]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: RFC 5280 and =
RFC 5055</span></font><font
size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt;font-family:"Times New =
Roman"'><o:p></o:p></span></font></p>

</div>

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

<p class=3DMsoNormal><a name=3D"_MailEndCompose"><font size=3D2 =
color=3D"#1f497d"
face=3DCalibri><span lang=3DSV =
style=3D'font-size:11.0pt;font-family:Calibri;
color:#1F497D'>Santosh,</span></font></a><font size=3D2 =
color=3D"#1f497d"
face=3DCalibri><span lang=3DSV =
style=3D'font-size:11.0pt;font-family:Calibri;
color:#1F497D'><o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DCalibri><span lang=3DSV
style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'><o:p>&nbsp;<=
/o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DCalibri><span
style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'>I believe =
the text
in 6.2. of RFC 5280 is correct, but I admit that it can be =
misunderstood.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DCalibri><span
style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'>The =
ambiguity lies
in the expression &#8220;the specified policies&#8221;. =
<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DCalibri><span
style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'><o:p>&nbsp;<=
/o:p></span></font></p>

<p class=3Dmsolistparagraph style=3D'text-indent:-.25in;mso-list:l0 =
level1 lfo2'><![if !supportLists]><font
size=3D2 color=3D"#1f497d" face=3DCalibri><span =
style=3D'font-size:11.0pt;font-family:
Calibri;color:#1F497D'><span style=3D'mso-list:Ignore'>1.<font size=3D1
face=3D"Times New Roman"><span style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></font></span></span></font><![endif]><font size=3D2 =
color=3D"#1f497d"
face=3DCalibri><span =
style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'>If
this is to mean, the policies provided in the self signed certificate, =
then it
becomes all wrong as the policy constraints extension does not include =
any
policies and because the policy constraints extension does not impose =
such
constraints.<o:p></o:p></span></font></p>

<p class=3Dmsolistparagraph style=3D'text-indent:-.25in;mso-list:l0 =
level1 lfo2'><![if !supportLists]><font
size=3D2 color=3D"#1f497d" face=3DCalibri><span =
style=3D'font-size:11.0pt;font-family:
Calibri;color:#1F497D'><span style=3D'mso-list:Ignore'>2.<font size=3D1
face=3D"Times New Roman"><span style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></font></span></span></font><![endif]><font size=3D2 =
color=3D"#1f497d"
face=3DCalibri><span =
style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'>If
this, however, is to mean the policies specified by the relying party, =
then it
becomes all correct. Because adding policy constraints =
(requireExplicitPolicy)
forces path validation to fail unless at least one of the set of RP =
allowed
policies are supported. &nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DCalibri><span
style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'><o:p>&nbsp;<=
/o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DCalibri><span
style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'>I read it =
as the
text describes case 2.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DCalibri><span
style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'><o:p>&nbsp;<=
/o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DCalibri><span
style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'>Could you =
elaborate
where 5055 should be aligned with 5280?<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DCalibri><span
style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'><o:p>&nbsp;<=
/o:p></span></font></p>

<div>

<p class=3DMsoNormal><b><font size=3D2 color=3Dmaroon face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;color:maroon;font-weight:bold'>Stefan =
Santesson</span></font></b><font
size=3D3 color=3D"#1f497d" face=3D"Times New Roman"><span lang=3DEN-GB
style=3D'font-size:12.0pt;font-family:"Times New =
Roman";color:#1F497D'><o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#400040" face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;color:#400040'>Senior Program =
Manager</span></font><font
size=3D3 color=3Dnavy face=3D"Times New Roman"><span lang=3DEN-GB =
style=3D'font-size:
12.0pt;font-family:"Times New =
Roman";color:navy'><o:p></o:p></span></font></p>

<p class=3DMsoNormal><b><font size=3D2 color=3D"#400040" =
face=3DArial><span lang=3DEN-GB
style=3D'font-size:10.0pt;color:#400040;font-weight:bold'>Windows =
Security,
Standards</span></font></b><font size=3D2 color=3D"#1f497d" =
face=3DCalibri><span
style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'><o:p></o:p><=
/span></font></p>

</div>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DCalibri><span
style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'><o:p>&nbsp;<=
/o:p></span></font></p>

<div style=3D'border:none;border-left:solid blue 1.5pt;padding:0in 0in =
0in 4.0pt'>

<div>

<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt =
0in 0in 0in'>

<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 =
face=3DTahoma><span
style=3D'font-family:Tahoma'> [e-mail]
[mailto:[e-mail]] <b><span =
style=3D'font-weight:bold'>On
Behalf Of </span></b><st1:PersonName w:st=3D"on">Santosh =
Chokhani</st1:PersonName><br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> den 29 augusti 2008 =
15:57<br>
<b><span style=3D'font-weight:bold'>To:</span></b> [e-mail]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RFC 5280 and RFC =
5055<o:p></o:p></span></font></p>

</div>

</div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DSV =
style=3D'font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'margin-left:.25in;text-indent:-.25in;mso-list:l1 level1 lfo4;
text-autospace:none'><![if !supportLists]><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt'><span style=3D'mso-list:Ignore'>1.<font =
size=3D1
face=3D"Times New Roman"><span style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp; </span></font></span></span></font><![endif]>RFC
5280, Section 6.2, states the following:<o:p></o:p></p>

<p class=3DMsoNormal =
style=3D'margin-left:.25in;text-autospace:none'><font size=3D2
face=3D"Courier New"><span =
style=3D'font-size:10.0pt;font-family:"Courier New"'>&#8220;For
example, a policy constraints extension could be included in the =
self-signed<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>&nbsp;&nbsp; =
certificate to
indicate that paths beginning with this trust anchor should be trusted =
only for
the specified policies.&#8221; &nbsp;This example should be corrected to =
either
point to certificate policies extension or to relate the last half of =
the
sentence to the semantics of require explicit =
policy.<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>2.&nbsp; RFC 5055 =
should be
enhanced to align with 5280.&nbsp; Aside from replacing the references, =
for
example, inputs to path validation may also include permitted and =
excluded
subtrees. &nbsp;</span></font><o:p></o:p></p>

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

<p class=3DMsoNormal><st1:PersonName w:st=3D"on"><font size=3D2 =
face=3DArial><span
 style=3D'font-size:10.0pt'>Santosh =
Chokhani</span></font></st1:PersonName><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt'>CygnaCom
Solutions, Inc,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><st1:Street w:st=3D"on"><st1:address =
w:st=3D"on"><font size=3D2
  face=3DArial><span style=3D'font-size:10.0pt'>7925 Jones Branch Drive, =
Suite 5200</span></font></st1:address></st1:Street><o:p></o:p></p>

<p class=3DMsoNormal><st1:place w:st=3D"on"><st1:City w:st=3D"on"><font =
size=3D2
  face=3DArial><span =
style=3D'font-size:10.0pt'>McLean</span></font></st1:City>, <st1:State
 w:st=3D"on">Virginia</st1:State> <st1:PostalCode =
w:st=3D"on">22102</st1:PostalCode></st1:place><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt'>(703)
270-3535<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt'>[e-mail]<o:p></o:p></span></font=
></p>

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

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

</div>

</div>

</body>

</html>

------_=_NextPart_001_01C91F5F.DEF02F64--



Received: from host-165-102-111-24.midco.net (host-165-102-111-24.midco.net [24.111.102.165]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m8PCv0wb092774 for <[e-mail]>; Thu, 25 Sep 2008 05:57:06 -0700 (MST) (envelope-from [e-mail])
Message-ID: <[e-mail]>
Date: Thu, 25 Sep 2008 07:54:58 -0500
Subject: Say goodbuy to bad condition.
From: kieth <[e-mail]>
To: [e-mail]
User-Agent: SquirrelMail/1.4.12
MIME-Version: 1.0
Content-Type: text/html;charset=utf-8
Content-Transfer-Encoding: 8bit
X-Confirm-Reading-To: <[e-mail]>
Disposition-Notification-To: <[e-mail]>
X-Priority: 3 (Normal)
Importance: Normal

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
</head>
<body bgcolor="#ffffff" text="#000000">
<div align=center> <a href="http://www.patternplural.com" target="_blank">
<img src="http://www.patternplural.com/logo.jpg" border=0 alt=""></a><br><br>
This message was sent to [e-mail]<br>
<a href="http://www.patternplural.com/unsubscribe.asp?mail=[e-mail]&key=067254309969a8">Unsubscribe</a> |
<a href="http://www.patternplural.com/manage.asp?mail=[e-mail]&key=45eca29e445769">Manage Subscriptions |
<a href="http://www.patternplural.com/privacy.asp?mail=[e-mail]&key=55a0163fd0a9cf">Privacy Policy</a><br>
To stop ALL email from our Newsletters, click <a href="http://www.patternplural.com/unsubscribe.asp?mail=[e-mail]&key=655dcb5120875c">here</a> to remove yourself from our lists.<br>
This email was sent by: CMD, 635 Massachusetts Ave., NW, Washington, DC 20001-3753<br>
© 2008 CMD<br>
</div>
</body>
</html>


Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m8P5cVdA062017 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Sep 2008 22:38:31 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8P5cVXW062016; Wed, 24 Sep 2008 22:38:31 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-dub.microsoft.com (smtp-dub.microsoft.com [213.199.138.181]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m8P5cI5f062003 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <[e-mail]>; Wed, 24 Sep 2008 22:38:29 -0700 (MST) (envelope-from [e-mail])
Received: from DUB-EXHUB-C301.europe.corp.microsoft.com (65.53.213.91) by DUB-EXGWY-E802.partners.extranet.microsoft.com (10.251.129.2) with Microsoft SMTP Server (TLS) id 8.1.291.1; Thu, 25 Sep 2008 06:38:18 +0100
Received: from EA-EXMSG-C332.europe.corp.microsoft.com ([169.254.2.73]) by DUB-EXHUB-C301.europe.corp.microsoft.com ([65.53.213.91]) with mapi; Thu, 25 Sep 2008 06:38:17 +0100
From: Stefan Santesson <[e-mail]>
To: Santosh Chokhani <[e-mail]>, "[e-mail]" <[e-mail]>
Date: Thu, 25 Sep 2008 06:38:15 +0100
Subject: RE: RFC 5280 and RFC 5055
Thread-Topic: RFC 5280 and RFC 5055
Thread-Index: AckJ3xTIlVgiPzEkRg2qerzLYLf0owU8MEFg
Message-ID: <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_9F11911AED01D24BAA1C2355723C3D3218DD8B631BEAEXMSGC332eu_"
MIME-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--_000_9F11911AED01D24BAA1C2355723C3D3218DD8B631BEAEXMSGC332eu_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Santosh,

I believe the text in 6.2. of RFC 5280 is correct, but I admit that it can =
be misunderstood.
The ambiguity lies in the expression "the specified policies".


1.       If this is to mean, the policies provided in the self signed certi=
ficate, then it becomes all wrong as the policy constraints extension does =
not include any policies and because the policy constraints extension does =
not impose such constraints.

2.       If this, however, is to mean the policies specified by the relying=
 party, then it becomes all correct. Because adding policy constraints (req=
uireExplicitPolicy) forces path validation to fail unless at least one of t=
he set of RP allowed policies are supported.

I read it as the text describes case 2.

Could you elaborate where 5055 should be aligned with 5280?

Stefan Santesson
Senior Program Manager
Windows Security, Standards

From: [e-mail] [mailto:[e-mail]] On=
 Behalf Of Santosh Chokhani
Sent: den 29 augusti 2008 15:57
To: [e-mail]
Subject: RFC 5280 and RFC 5055

1.  RFC 5280, Section 6.2, states the following:
"For example, a policy constraints extension could be included in the self-=
signed
   certificate to indicate that paths beginning with this trust anchor shou=
ld be trusted only for the specified policies."  This example should be cor=
rected to either point to certificate policies extension or to relate the l=
ast half of the sentence to the semantics of require explicit policy.

2.  RFC 5055 should be enhanced to align with 5280.  Aside from replacing t=
he references, for example, inputs to path validation may also include perm=
itted and excluded subtrees.

Santosh Chokhani
CygnaCom Solutions, Inc,
7925 Jones Branch Drive, Suite 5200
McLean, Virginia 22102
[phone]
[e-mail]



--_000_9F11911AED01D24BAA1C2355723C3D3218DD8B631BEAEXMSGC332eu_
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-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:"\@SimSun";
	panose-1:2 1 6 0 3 1 1 1 1 1;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Arial","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
	{mso-style-priority:34;
	margin-top:0cm;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:36.0pt;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Arial","sans-serif";}
span.EmailStyle17
	{mso-style-type:personal;
	font-family:"Arial","sans-serif";
	color:windowtext;}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.Section1
	{page:Section1;}
 /* List Definitions */
 @list l0
	{mso-list-id:915365297;
	mso-list-type:hybrid;
	mso-list-template-ids:901964120 69009423 69009433 69009435 69009423 690094=
33 69009435 69009423 69009433 69009435;}
@list l0:level1
	{mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l1
	{mso-list-id:1929194249;
	mso-list-type:hybrid;
	mso-list-template-ids:290648398 67698703 67698713 67698715 67698703 676987=
13 67698715 67698703 67698713 67698715;}
@list l1:level1
	{mso-level-tab-stop:18.0pt;
	mso-level-number-position:left;
	margin-left:18.0pt;
	text-indent:-18.0pt;}
@list l1:level2
	{mso-level-tab-stop:72.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l1:level3
	{mso-level-tab-stop:108.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l1:level4
	{mso-level-tab-stop:144.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l1:level5
	{mso-level-tab-stop:180.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l1:level6
	{mso-level-tab-stop:216.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l1:level7
	{mso-level-tab-stop:252.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l1:level8
	{mso-level-tab-stop:288.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l1:level9
	{mso-level-tab-stop:324.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
ol
	{margin-bottom:0cm;}
ul
	{margin-bottom:0cm;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DSV link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><a name=3D"_MailEndCompose"><span style=3D'font-size:1=
1.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'>Santosh,<o:p></o:p></span=
></a></p>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Calibri","sans-serif";
color:#1F497D'>I believe the text in 6.2. of RFC 5280 is correct, but I adm=
it
that it can be misunderstood.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Calibri","sans-serif";
color:#1F497D'>The ambiguity lies in the expression &#8220;the specified
policies&#8221;. <o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoListParagraph style=3D'text-indent:-18.0pt;mso-list:l0 level1=
 lfo3'><![if !supportLists]><span
lang=3DEN-US style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><span style=3D'mso-list:Ignore'>1.<span style=3D'font:7.0pt =
"Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span></span><![endif]><span lang=3DEN-US style=3D'font-size:11.0pt=
;
font-family:"Calibri","sans-serif";color:#1F497D'>If this is to mean, the
policies provided in the self signed certificate, then it becomes all wrong=
 as
the policy constraints extension does not include any policies and because =
the
policy constraints extension does not impose such constraints.<o:p></o:p></=
span></p>

<p class=3DMsoListParagraph style=3D'text-indent:-18.0pt;mso-list:l0 level1=
 lfo3'><![if !supportLists]><span
lang=3DEN-US style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><span style=3D'mso-list:Ignore'>2.<span style=3D'font:7.0pt =
"Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span></span><![endif]><span lang=3DEN-US style=3D'font-size:11.0pt=
;
font-family:"Calibri","sans-serif";color:#1F497D'>If this, however, is to m=
ean
the policies specified by the relying party, then it becomes all correct. B=
ecause
adding policy constraints (requireExplicitPolicy) forces path validation to
fail unless at least one of the set of RP allowed policies are supported. &=
nbsp;<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Calibri","sans-serif";
color:#1F497D'>I read it as the text describes case 2.<o:p></o:p></span></p=
>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Calibri","sans-serif";
color:#1F497D'>Could you elaborate where 5055 should be aligned with 5280?<=
o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<div>

<p class=3DMsoNormal><b><span lang=3DEN-GB style=3D'color:maroon'>Stefan Sa=
ntesson</span></b><span
lang=3DEN-GB style=3D'font-size:12.0pt;font-family:"Times New Roman","serif=
";
color:#1F497D'><o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-GB style=3D'color:#400040'>Senior Prog=
ram
Manager</span><span lang=3DEN-GB style=3D'font-size:12.0pt;font-family:"Tim=
es New Roman","serif";
color:navy'><o:p></o:p></span></p>

<p class=3DMsoNormal><b><span lang=3DEN-GB style=3D'color:#400040'>Windows =
Security,
Standards</span></b><span lang=3DEN-US style=3D'font-size:11.0pt;font-famil=
y:"Calibri","sans-serif";
color:#1F497D'><o:p></o:p></span></p>

</div>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<div style=3D'border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm =
4.0pt'>

<div>

<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm =
0cm 0cm'>

<p class=3DMsoNormal><b><span lang=3DEN-US style=3D'font-family:"Tahoma","s=
ans-serif"'>From:</span></b><span
lang=3DEN-US style=3D'font-family:"Tahoma","sans-serif"'>
[e-mail] [mailto:[e-mail]] <b>On Be=
half
Of </b>Santosh Chokhani<br>
<b>Sent:</b> den 29 augusti 2008 15:57<br>
<b>To:</b> [e-mail]<br>
<b>Subject:</b> RFC 5280 and RFC 5055<o:p></o:p></span></p>

</div>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal style=3D'margin-left:18.0pt;text-indent:-18.0pt;mso-li=
st:l1 level1 lfo2;
text-autospace:none'><![if !supportLists]><span lang=3DEN-US><span
style=3D'mso-list:Ignore'>1.<span style=3D'font:7.0pt "Times New Roman"'>&n=
bsp; </span></span></span><![endif]><span
lang=3DEN-US>RFC 5280, Section 6.2, states the following:<o:p></o:p></span>=
</p>

<p class=3DMsoNormal style=3D'margin-left:18.0pt;text-autospace:none'><span
lang=3DEN-US style=3D'font-family:"Courier New"'>&#8220;For example, a poli=
cy
constraints extension could be included in the self-signed<o:p></o:p></span=
></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><span lang=3DEN-US
style=3D'font-family:"Courier New"'>&nbsp;&nbsp; certificate to indicate th=
at
paths beginning with this trust anchor should be trusted only for the speci=
fied
policies.&#8221; &nbsp;This example should be corrected to either point to
certificate policies extension or to relate the last half of the sentence t=
o
the semantics of require explicit policy.<o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><span lang=3DEN-US
style=3D'font-family:"Courier New"'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><span lang=3DEN-US
style=3D'font-family:"Courier New"'>2.&nbsp; RFC 5055 should be enhanced to=
 align
with 5280.&nbsp; Aside from replacing the references, for example, inputs t=
o
path validation may also include permitted and excluded subtrees. &nbsp;</s=
pan><span
lang=3DEN-US><o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US>Santosh Chokhani<o:p></o:p></span><=
/p>

<p class=3DMsoNormal><span lang=3DEN-US>CygnaCom Solutions, Inc,<o:p></o:p>=
</span></p>

<p class=3DMsoNormal><span lang=3DEN-US>7925 Jones Branch Drive, Suite 5200=
<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US>McLean, Virginia 22102<o:p></o:p></=
span></p>

<p class=3DMsoNormal><span lang=3DEN-US>[phone]<o:p></o:p></span></p=
>

<p class=3DMsoNormal><span lang=3DEN-US>[e-mail]<o:p></o:p></=
span></p>

<p class=3DMsoNormal><span lang=3DEN-US>&nbsp;<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>

</div>

</div>

</body>

</html>

--_000_9F11911AED01D24BAA1C2355723C3D3218DD8B631BEAEXMSGC332eu_--



Received: from 59.165.2.233.man-static.vsnl.net.in (59.165.2.233.man-static.vsnl.net.in [59.165.2.233] (may be forged)) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m8P5UYDL061364 for <[e-mail]>; Wed, 24 Sep 2008 22:30:37 -0700 (MST) (envelope-from [e-mail])
Message-ID: <[e-mail]>
Date: Thu, 25 Sep 2008 11:00:33 +05-30
Subject: Want to have fantastic nights?
From: boran <[e-mail]>
To: [e-mail]
User-Agent: SquirrelMail/1.4.12
MIME-Version: 1.0
Content-Type: text/html;charset=utf-8
Content-Transfer-Encoding: 8bit
X-Confirm-Reading-To: <[e-mail]>
Disposition-Notification-To: <[e-mail]>
X-Priority: 3 (Normal)
Importance: Normal

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
</head>
<body bgcolor="#ffffff" text="#000000">
<div align=center> <a href="http://www.neighboragree.com" target="_blank">
<img src="http://www.neighboragree.com/welcome.jpg" border=0 alt=""></a><br><br>
This message was sent to [e-mail]<br>
<a href="http://www.neighboragree.com/unsubscribe.asp?mail=[e-mail]&key=b22167fbd04015">Unsubscribe</a> |
<a href="http://www.neighboragree.com/manage.asp?mail=[e-mail]&key=2c8456fc39aed0">Manage Subscriptions |
<a href="http://www.neighboragree.com/privacy.asp?mail=[e-mail]&key=4d4cb3cd71178d">Privacy Policy</a><br>
To stop ALL email from our Newsletters, click <a href="http://www.neighboragree.com/unsubscribe.asp?mail=[e-mail]&key=b36428498e0559">here</a> to remove yourself from our lists.<br>
This email was sent by: CMD, 635 Massachusetts Ave., NW, Washington, DC 20001-3753<br>
© 2008 CMD<br>
</div>
</body>
</html>


Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m8P20CoP048228 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Sep 2008 19:00:12 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8P20CpE048227; Wed, 24 Sep 2008 19:00:12 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-dub.microsoft.com (smtp-dub.microsoft.com [213.199.138.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m8P200Dk048211 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <[e-mail]>; Wed, 24 Sep 2008 19:00:11 -0700 (MST) (envelope-from [e-mail])
Received: from DUB-EXHUB-C301.europe.corp.microsoft.com (65.53.213.91) by DUB-EXGWY-E801.partners.extranet.microsoft.com (10.251.129.1) with Microsoft SMTP Server (TLS) id 8.1.291.1; Thu, 25 Sep 2008 03:00:00 +0100
Received: from EA-EXMSG-C332.europe.corp.microsoft.com ([169.254.2.73]) by DUB-EXHUB-C301.europe.corp.microsoft.com ([65.53.213.91]) with mapi; Thu, 25 Sep 2008 03:00:00 +0100
From: Stefan Santesson <[e-mail]>
To: "David A. Cooper" <[e-mail]>, pkix <[e-mail]>
Date: Thu, 25 Sep 2008 02:59:57 +0100
Subject: RE: need information about use of subjectInfoAccess extension
Thread-Topic: need information about use of subjectInfoAccess extension
Thread-Index: AckNQ42ZaI9E0TuwTQCBAny3adCX+QRbfGrg
Message-ID: <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

David,

Windows Vista path validation support SIA.
However, using SIA for path discovery is a double edged sword and have to b=
e used with caution in controlled PKI environments.

As we don't have any standard and working methodology for how to build path=
s top down Using SIA in a mesh PKI, this may face the client with un-resolv=
able path construction graphs.


Stefan Santesson
Senior Program Manager
Windows Security, Standards


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> On Behalf Of David A. Cooper
> Sent: den 2 september 2008 22:46
> To: pkix
> Subject: need information about use of subjectInfoAccess extension
>
>
> All,
>
> I have been asked to begin collecting the information necessary to
> demonstrate that RFC 5280 is ready to advance to the draft standard
> stage, including demonstrating that there are independent
> implementations of each of the features in the document.
>
> I do not expect to have trouble finding CAs that can issue certificates
> with any of the extensions mentioned in the document, and I shouldn't
> have problems finding path validation clients that can process most of
> the extensions.  I am unsure, however, about the availability of
> clients
> that use the subjectInfoAccess extension.
>
> Does anyone know of any path validation clients that use the
> id-ad-caRepository access method of the SIA extension to aid in path
> discovery?
>
> Does anyone know of any clients that use the id-ad-timeStamping access
> method to aid in locating a time stamping authority?
>
>
> Thanks,
>
> Dave
>



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m8P151g0044614 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Sep 2008 18:05:02 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8P151xJ044613; Wed, 24 Sep 2008 18:05:01 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-dub.microsoft.com (smtp-dub.microsoft.com [213.199.138.181]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m8P14n3T044590 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <[e-mail]>; Wed, 24 Sep 2008 18:05:00 -0700 (MST) (envelope-from [e-mail])
Received: from DUB-EXHUB-C301.europe.corp.microsoft.com (65.53.213.91) by DUB-EXGWY-E802.partners.extranet.microsoft.com (10.251.129.2) with Microsoft SMTP Server (TLS) id 8.1.291.1; Thu, 25 Sep 2008 02:04:48 +0100
Received: from EA-EXMSG-C332.europe.corp.microsoft.com ([169.254.2.73]) by DUB-EXHUB-C301.europe.corp.microsoft.com ([65.53.213.91]) with mapi; Thu, 25 Sep 2008 02:04:48 +0100
From: Stefan Santesson <[e-mail]>
To: Russ Housley <[e-mail]>, "[e-mail]" <[e-mail]>
Date: Thu, 25 Sep 2008 02:04:44 +0100
Subject: RE: Question about implementation of name constraints
Thread-Topic: Question about implementation of name constraints
Thread-Index: Ackam9Mgn6EhbTiYQ46B6js4NpHeOQEDdg8Q
Message-ID: <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Russ, here are some answers for Microsoft CAPI

The questions:

> (a) the directoryName form is constrained using the domainComponent
> attribute?

If directoryName is constrained, then this does only constrain directoryNam=
e. It will not constrain any rfc822Name, URI or dNSName.

> (b) the dNSName form is constrained?

Then this will constrain dNSName


> (c) the uniformResourceIdentifier is constrained to a particular domain
> name?

Then this will constrain URIs

> For (b) and (c), I'm assuming the  following parts of RFC 5280 are
> followed (Leading dot =3D alows subsomain. no leading dot =3D host):

Yes, this logic is implemented.




Stefan Santesson
Senior Program Manager
Windows Security, Standards


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> On Behalf Of Russ Housley
> Sent: den 19 september 2008 22:16
> To: [e-mail]
> Subject: Question about implementation of name constraints
>
>
> First I want to provide some background from RFC 5280, then I have a
> three-part question for implementors.
>
> In Section 4.2, we learn that the name constraints extension MUST be
> recognized:
>
>      At a minimum, applications conforming to this profile MUST
> recognize
>     the following extensions: key usage (Section 4.2.1.3), certificate
>     policies (Section 4.2.1.4), subject alternative name (Section
>     4.2.1.6), basic constraints (Section 4.2.1.9), name constraints
>     (Section 4.2.1.10), policy constraints (Section 4.2.1.11), extended
>     key usage (Section 4.2.1.12), and inhibit anyPolicy (Section
>     4.2.1.14).
>
> Then, in Section 4.2.1.10 we learn that the name constraints
> extension MUST only appear in CA certificates and that the
> constraints apply to both the subject name and the subject alt name:
>
>     The name constraints extension, which MUST be used only in a CA
>     certificate, indicates a name space within which all subject names
> in
>     subsequent certificates in a certification path MUST be located.
>     Restrictions apply to the subject distinguished name and apply to
>     subject alternative names.  Restrictions apply only when the
>     specified name form is present.  If no name of the type is in the
>     certificate, the certificate is acceptable.
>
> We also learn that the name constraints extension MUST be critical:
>
>     ... Conforming CAs MUST mark this extension as
>     critical and SHOULD NOT impose name constraints on the x400Address,
>     ediPartyName, or registeredID name forms. ...
>
> Section 4.2.1.10 also has some requirements for applications that use
> the certificate:
>
>     Applications conforming to this profile MUST be able to process
> name
>     constraints that are imposed on the directoryName name form and
>     SHOULD be able to process name constraints that are imposed on the
>     rfc822Name, uniformResourceIdentifier, dNSName, and iPAddress name
>     forms.  If a name constraints extension that is marked as critical
>     imposes constraints on a particular name form, and an instance of
>     that name form appears in the subject field or subjectAltName
>     extension of a subsequent certificate, then the application MUST
>     either process the constraint or reject the certificate.
>
> So, now my question to implementors.  I'm trying to find out what
> will really happen if a CA tries to use name constraints to constrain
> a domain name.
>
> If your implementation encounters a certification path where one or
> more of the CA certificates includes a critical name constraints
> extension, will the implementation accept the certification path or
> reject it when:
>
> (a) the directoryName form is constrained using the domainComponent
> attribute?
>
> (b) the dNSName form is constrained?
>
> (c) the uniformResourceIdentifier is constrained to a particular domain
> name?
>
> For (b) and (c), I'm assuming the  following parts of RFC 5280 are
> followed:
>
>     For URIs, the constraint applies to the host part of the name.  The
>     constraint MUST be specified as a fully qualified domain name and
> MAY
>     specify a host or a domain.  Examples would be "host.example.com"
> and
>     ".example.com".  When the constraint begins with a period, it MAY
> be
>     expanded with one or more labels.  That is, the constraint
>     ".example.com" is satisfied by both host.example.com and
>     my.host.example.com.  However, the constraint ".example.com" is not
>     satisfied by "example.com".  When the constraint does not begin
> with
>     a period, it specifies a host.  If a constraint is applied to the
>     uniformResourceIdentifier name form and a subsequent certificate
>     includes a subjectAltName extension with a
> uniformResourceIdentifier
>     that does not include an authority component with a host name
>     specified as a fully qualified domain name (e.g., if the URI either
>     does not include an authority component or includes an authority
>     component in which the host name is specified as an IP address),
> then
>     the application MUST reject the certificate.
>
>     DNS name restrictions are expressed as host.example.com.  Any DNS
>     name that can be constructed by simply adding zero or more labels
> to
>     the left-hand side of the name satisfies the name constraint.  For
>     example, www.host.example.com would satisfy the constraint but
>     host1.example.com would not.
>
> Thanks for your help in advance,
>    Russ
>



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m8OHKLio014137 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Sep 2008 10:20:21 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8OHKK49014136; Wed, 24 Sep 2008 10:20:20 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mailhost.auckland.ac.nz (curly.its.auckland.ac.nz [130.216.12.33]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m8OHKJ82014130 for <[e-mail]>; Wed, 24 Sep 2008 10:20:20 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id BFD089D181; Thu, 25 Sep 2008 05:20:18 +1200 (NZST)
X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz
Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (curly.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YQ1N0OYVd5Xc; Thu, 25 Sep 2008 05:20:18 +1200 (NZST)
Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 49B879D17D; Thu, 25 Sep 2008 05:20:17 +1200 (NZST)
Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 039D119EC0BA; Thu, 25 Sep 2008 05:20:17 +1200 (NZST)
Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from <[e-mail]>) id 1KiY2C-0005aj-TJ; Thu, 25 Sep 2008 05:20:16 +1200
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: Question about implementation of name constraints
In-Reply-To: <[e-mail]>
Message-Id: <[e-mail]>
Date: Thu, 25 Sep 2008 05:20:16 +1200
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Russ Housley <[e-mail]> writes:

>If your implementation encounters a certification path where one or more of
>the CA certificates includes a critical name constraints extension, will the
>implementation accept the certification path or reject it when:
>
>(a) the directoryName form is constrained using the domainComponent attribute?
>
>(b) the dNSName form is constrained?
>
>(c) the uniformResourceIdentifier is constrained to a particular domain name?

Hmm, I'm not sure if I understand the question correctly but if you're asking
"will you apply name constraints from CA -> subject certs" then the answer is
"yes".

Peter.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m8OHAH4q012941 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Sep 2008 10:10:17 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8OHAHOM012940; Wed, 24 Sep 2008 10:10:17 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mailhost.auckland.ac.nz (curly.its.auckland.ac.nz [130.216.12.33]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m8OHA6Dd012908 for <[e-mail]>; Wed, 24 Sep 2008 10:10:17 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id E38D09D13A; Thu, 25 Sep 2008 05:10:05 +1200 (NZST)
X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz
Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (curly.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9+yEUmv9ViER; Thu, 25 Sep 2008 05:10:05 +1200 (NZST)
Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 47C8A9D139; Thu, 25 Sep 2008 05:10:04 +1200 (NZST)
Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id E7C6719EC0BA; Thu, 25 Sep 2008 05:10:03 +1200 (NZST)
Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from <[e-mail]>) id 1KiXsJ-0004gt-QZ; Thu, 25 Sep 2008 05:10:03 +1200
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: Possible Errata on RFC 2560
In-Reply-To: <057201c91b5b$f526bba0$df7432e0$@com>
Message-Id: <[e-mail]>
Date: Thu, 25 Sep 2008 05:10:03 +1200
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Jim Schaad" <[e-mail]> writes:

>This does not tell me the ASN.1 type of the nonce.  I assume, but do not know
>for sure that it is suppose to be an OCTET STRING.

Its supposed to be an INTEGER AFAIK but implementations treat it as a INTEGER
form of an OCTET STRING hole.  Actually there are (or at least were a few
years ago) so many broken interpretations of this (INTEGER hole, OCTET STRING
hole, OCTET STRING inside another OCTET STRING, and finally just raw binary
data with no ASN.1 structure at all) that it's safest to treat it on reading
as a blob.

Peter.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m8OEvvJo099837 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Sep 2008 07:57:57 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8OEvvoM099836; Wed, 24 Sep 2008 07:57:57 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [8.8.40.152]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m8OEvkNO099814 for <[e-mail]>; Wed, 24 Sep 2008 07:57:56 -0700 (MST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
Received: (qmail 28327 invoked by uid 0); 24 Sep 2008 13:08:28 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (72.245.120.38) by woodstock.binhost.com with SMTP; 24 Sep 2008 13:08:28 -0000
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Wed, 24 Sep 2008 09:05:49 -0400
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: RE: Comments on draft-ietf-pkix-ecc-subpubkeyinfo-08
In-Reply-To: <A6CB9F5557F049C9BC950FF3A5C46586@Wylie>
References: <[e-mail]> <A6CB9F5557F049C9BC950FF3A5C46586@Wylie>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Two points.

My initial reaction to implicitCurve is that many people that support 
DSA already deal with parameter inheritance in that context.  So, it 
may not be a burden to keep this capability in the 
specification.  Are implementors finding this to be a problem?

It is probably a good idea to avoid the down reference at this 
point.  There are several ways to resolve this concern.  One simple 
way is to include two ASN.1 modules in the this document.

Russ

At 06:56 PM 9/23/2008, Turner, Sean P. wrote:

>Carl,
>
>Thanks for taking the time to review the draft.  Responses in-line.
>
>spt
>
> >-----Original Message-----
> >From: [e-mail]
> >[mailto:[e-mail]] On Behalf Of Carl Wallace
> >Sent: Tuesday, September 23, 2008 4:07 PM
> >To: [e-mail]
> >Subject: Comments on draft-ietf-pkix-ecc-subpubkeyinfo-08
>
>snip
>
> >- In section 2.1.1, why is implicitCurve not deprecated along
> >with specifiedCurve?  The text states that implicitCurve is
> >only supported when namedCurve is not used and there is no
> >option other than namedCurve available.
>
>It does seem like this choice ought to be deprecated too because it says you
>always use namedCurve.
>
> >- Why is A.2 the informative module?  Most sections in the
> >spec reference definitions from A.2.
>
>I figured this was a style thing. I like the class definition way of
>defining the keys and curves because I think it's clearer.  BUT, we do have
>this problem of a dependancy on draft-ietf-pkix-new-asn1.  If we used the
>"old" way of defining the structures in the main body of the document, I'd
>recommend blowing away the all of the new ASN.1 and putting it in Jim/Paul's
>draft-ietf-pkix-new-asn1 ID or some other ID to not slow down completion.
>
>ALL: Should we only use the "old" ASN.1 in the document and move all the
>"new" ASN.1 to another document?
>
> >- Given the amount of repetition between the ASN.1 modules, it
> >may make more sense to define all of the structures and OIDs
> >once and import them into one module that uses information
> >objects and one that doesn't.  I think ECParameters is the
> >only structure that would need to go in the module that
> >doesn't use information objects.
>
>I made one for curves and one for algorithm IDs, key format, and parameter
>structures.  Then imported the curves, IDs, formats, and structures in the
>information object module and the curves in to the ECParameters module. I
>think it took off 2 pages, but there ought to be less chances of me copying
>things incorrectly.
>
> >- Expand EC in third paragraph of section 1
> >- "algorithms" should be singular in the first sentence of section 2.1
> >- Provide a reference to 5280 where SubjectPublicKeyInfo is
> >defined in Section 2
> >- In 2.1.2, change "fall in to different" to "fall in two
> >different" or "fall into different"
> >- Rewrite last sentence of section 3 to remove the condition
> >since the certificate MUST assert keyAgreement or make the
> >statement about asserting encipherOnly or decipherOnly one
> >time instead of once per certificate type.
> >- In Security Considerations, change "desired have value" to
> >"desired hash value"
> >- In second paragraph of section 5, "implementations" should
> >be singular.
>
>Fixed
>
> >- Where there are references to X9.62, the names of the
> >structures should be the same.  ECParameters and
> >SpecifiedCurve appear as ECDomainParameters and
> >SpecifiedECDomain in X9.62.
>
>There's been lots of name changes to these four fields. We point to both
>SEC1 and ANSI X9 and we also have RFC 3279.
>What we're calling ECParameters:
>   RFC3279 called them EcpkParameters
>   SEC1 v1 called them Parameters
>   ANSI X9.62:2005 called them ECDomainParameters
>What we're calling namedCurve:
>   RFC3279 called them namedCurve
>   SEC1 v1 called them namedCurve
>   ANSI X9.62:2005 called them named
>What we're calling specifiedCurve:
>   RFC3279 called them ecParameters
>   SEC1 called them ecParameters
>   ANSI X9.62:2005 called them specified
>What we're calling SpecifiedCurve:
>   RFC3279 called them ECParameters
>   SEC1 called them ECParameters
>   ANSI X9.62:2005 called them SpecifiedECDomain
>What we're calling implicitCurve:
>   RFC3279 called them implicitlyCA
>   SEC1 called them implicitCA
>   ANSI X9.62:2005 called them implicitCA
>
>Seemed like we could do our own thing here.  ECParameters makes sense as a
>name for the top level because it's the parameters for the EC.  I aligned
>the names to namedCurve, specifiedCurve, and implicitCurve because they're
>all variations on a theme: OID, full specification, and implied (can come
>from places other than the CA's cert).  I changed the name of SpecifedCurve
>to SpecifiedECDomain parameters but left the other field names as is.



Received: from 75-121-143-213.dyn.centurytel.net (d2-16.rb.vcr.centurytel.net [69.29.237.16]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m8OCTk0m081914 for <[e-mail]>; Wed, 24 Sep 2008 05:29:48 -0700 (MST) (envelope-from [e-mail])
Message-ID: <[e-mail]>
Date: Wed, 24 Sep 2008 07:29:48 -0700
Subject: We are sure that lengthening will help you boost your intimate life!
From: mohammd <[e-mail]>
To: [e-mail]
User-Agent: SquirrelMail/1.4.12
MIME-Version: 1.0
Content-Type: text/html;charset=utf-8
Content-Transfer-Encoding: 8bit
X-Confirm-Reading-To: <[e-mail]>
Disposition-Notification-To: <[e-mail]>
X-Priority: 3 (Normal)
Importance: Normal

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
</head>
<body bgcolor="#ffffff" text="#000000">
<div align=center> <a href="http://www.syllablegenerosity.com" target="_blank">
<img src="http://www.syllablegenerosity.com/header.jpg" border=0 alt=""></a><br><br>
This message was sent to [e-mail]<br>
<a href="http://www.syllablegenerosity.com/unsubscribe.asp?mail=[e-mail]&key=d85faa92864751">Unsubscribe</a> |
<a href="http://www.syllablegenerosity.com/manage.asp?mail=[e-mail]&key=de3740d1b45dde">Manage Subscriptions |
<a href="http://www.syllablegenerosity.com/privacy.asp?mail=[e-mail]&key=a2d056c4cf8096">Privacy Policy</a><br>
To stop ALL email from our Newsletters, click <a href="http://www.syllablegenerosity.com/unsubscribe.asp?mail=[e-mail]&key=91069e377761f2">here</a> to remove yourself from our lists.<br>
This email was sent by: CMD, 635 Massachusetts Ave., NW, Washington, DC 20001-3753<br>
© 2008 CMD<br>
</div>
</body>
</html>


Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m8NMv93C009208 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Sep 2008 15:57:09 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8NMv96S009207; Tue, 23 Sep 2008 15:57:09 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp106.biz.mail.re2.yahoo.com (smtp106.biz.mail.re2.yahoo.com [206.190.52.175]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m8NMuvf8009198 for <[e-mail]>; Tue, 23 Sep 2008 15:57:08 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 33693 invoked from network); 23 Sep 2008 22:56:57 -0000
Received: from unknown (HELO Wylie) ([e-mail]@96.241.103.66 with login) by smtp106.biz.mail.re2.yahoo.com with SMTP; 23 Sep 2008 22:56:57 -0000
X-YMail-OSG: IS3GjcYVM1mz_XfjXrGlXagNkBH2DQofQVPthtHJe_u7SHTxZinoH.ZPppmIkqebx20Hxxm..zN75j3P0XCYRmhq2sabQjEC8JvDh_mvRVr9p_MhM9KLo4wL0TyxXEXoPCXHqoPLsvWvndLpp2mdfaOj2A--
X-Yahoo-Newman-Property: ymail-3
From: "Turner, Sean P." <[e-mail]>
To: "'Carl Wallace'" <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: RE: Comments on draft-ietf-pkix-ecc-subpubkeyinfo-08
Date: Tue, 23 Sep 2008 18:56:52 -0400
Organization: IECA, Inc.
Message-ID: <A6CB9F5557F049C9BC950FF3A5C46586@Wylie>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
Thread-Index: Ackdt/28XEFhtuEyTTGM8l+XRbRh1gACg59g
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Carl,

Thanks for taking the time to review the draft.  Responses in-line.

spt 

>-----Original Message-----
>From: [e-mail] 
>[mailto:[e-mail]] On Behalf Of Carl Wallace
>Sent: Tuesday, September 23, 2008 4:07 PM
>To: [e-mail]
>Subject: Comments on draft-ietf-pkix-ecc-subpubkeyinfo-08

snip

>- In section 2.1.1, why is implicitCurve not deprecated along 
>with specifiedCurve?  The text states that implicitCurve is 
>only supported when namedCurve is not used and there is no 
>option other than namedCurve available.

It does seem like this choice ought to be deprecated too because it says you
always use namedCurve.

>- Why is A.2 the informative module?  Most sections in the 
>spec reference definitions from A.2.  

I figured this was a style thing. I like the class definition way of
defining the keys and curves because I think it's clearer.  BUT, we do have
this problem of a dependancy on draft-ietf-pkix-new-asn1.  If we used the
"old" way of defining the structures in the main body of the document, I'd
recommend blowing away the all of the new ASN.1 and putting it in Jim/Paul's
draft-ietf-pkix-new-asn1 ID or some other ID to not slow down completion.

ALL: Should we only use the "old" ASN.1 in the document and move all the
"new" ASN.1 to another document?  

>- Given the amount of repetition between the ASN.1 modules, it 
>may make more sense to define all of the structures and OIDs 
>once and import them into one module that uses information 
>objects and one that doesn't.  I think ECParameters is the 
>only structure that would need to go in the module that 
>doesn't use information objects.

I made one for curves and one for algorithm IDs, key format, and parameter
structures.  Then imported the curves, IDs, formats, and structures in the
information object module and the curves in to the ECParameters module. I
think it took off 2 pages, but there ought to be less chances of me copying
things incorrectly.

>- Expand EC in third paragraph of section 1
>- "algorithms" should be singular in the first sentence of section 2.1
>- Provide a reference to 5280 where SubjectPublicKeyInfo is 
>defined in Section 2
>- In 2.1.2, change "fall in to different" to "fall in two 
>different" or "fall into different"
>- Rewrite last sentence of section 3 to remove the condition 
>since the certificate MUST assert keyAgreement or make the 
>statement about asserting encipherOnly or decipherOnly one 
>time instead of once per certificate type.
>- In Security Considerations, change "desired have value" to 
>"desired hash value"
>- In second paragraph of section 5, "implementations" should 
>be singular.

Fixed

>- Where there are references to X9.62, the names of the 
>structures should be the same.  ECParameters and 
>SpecifiedCurve appear as ECDomainParameters and 
>SpecifiedECDomain in X9.62.

There's been lots of name changes to these four fields. We point to both
SEC1 and ANSI X9 and we also have RFC 3279.  
What we're calling ECParameters:
  RFC3279 called them EcpkParameters
  SEC1 v1 called them Parameters
  ANSI X9.62:2005 called them ECDomainParameters
What we're calling namedCurve:
  RFC3279 called them namedCurve
  SEC1 v1 called them namedCurve
  ANSI X9.62:2005 called them named
What we're calling specifiedCurve:
  RFC3279 called them ecParameters
  SEC1 called them ecParameters
  ANSI X9.62:2005 called them specified
What we're calling SpecifiedCurve:
  RFC3279 called them ECParameters
  SEC1 called them ECParameters
  ANSI X9.62:2005 called them SpecifiedECDomain
What we're calling implicitCurve:
  RFC3279 called them implicitlyCA
  SEC1 called them implicitCA
  ANSI X9.62:2005 called them implicitCA

Seemed like we could do our own thing here.  ECParameters makes sense as a
name for the top level because it's the parameters for the EC.  I aligned
the names to namedCurve, specifiedCurve, and implicitCurve because they're
all variations on a theme: OID, full specification, and implied (can come
from places other than the CA's cert).  I changed the name of SpecifedCurve
to SpecifiedECDomain parameters but left the other field names as is.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m8NLBqvJ000845 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Sep 2008 14:11:52 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8NLBqCd000842; Tue, 23 Sep 2008 14:11:52 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from QMTA08.emeryville.ca.mail.comcast.net (qmta08.emeryville.ca.mail.comcast.net [76.96.30.80]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m8NLBfZB000819 for <[e-mail]>; Tue, 23 Sep 2008 14:11:52 -0700 (MST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
Received: from OMTA05.emeryville.ca.mail.comcast.net ([76.96.30.43]) by QMTA08.emeryville.ca.mail.comcast.net with comcast id JGni1a00D0vp7WLA8MBhA1; Tue, 23 Sep 2008 21:11:41 +0000
Received: from MIKES-LAPTOM.comcast.net ([69.140.151.110]) by OMTA05.emeryville.ca.mail.comcast.net with comcast id JMBf1a00a2P9w058RMBgyR; Tue, 23 Sep 2008 21:11:41 +0000
X-Authority-Analysis: v=1.0 c=1 a=Z3teKcA4MD0A:10 a=b9Or9LQKI0IA:10 a=7ucbOL6sA7wlmNDeqKQA:9 a=WNq0cwfsvYXmXilO_h0Idq4KTkQA:4 a=50e4U0PicR4A:10
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Tue, 23 Sep 2008 17:11:37 -0400
To: Paul Hoffman <[e-mail]>, "Santosh Chokhani" <[e-mail]>, <[e-mail]>
From: Michael StJohns <[e-mail]>
Subject: RE: I-D ACTION:draft-ietf-pkix-ecc-subpubkeyinfo-08.txt
In-Reply-To: <p06240832c4fee49f6114@[10.20.30.152]>
References: <[e-mail]> <[e-mail]> <p06240832c4fee49f6114@[10.20.30.152]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Paul 

It may actually make sense to do this for one specific reason:  Most of the standard curves are "chosen" in a manner to make them efficient to implement.  As near as I can tell from the reading I've been doing lately, you can change the base point without losing this property. And the code delta for doing a namedCurve vs a namedCurveWithG is simply a matter of where you pull G from (the algorithmIdentifier or the internal definition) and is the same for all curves which use the same base curve parameters (e.g. everything constant except G).

I've been trying to re-find the discussion about why you might want to do multiple Gs for a curve - I read it a few months back, but trying to sieve it out of google again is failing.

One possible encoding for the algorithm parameters (new CHOICE)

namedCurveWithG ::= SEQUENCE {
        OBJECT IDENTIFIER curve,
        Point g  OPTIONAL }

Point ::= SEQUENCE {
        INTEGER x,
        INTEGER y }

for example.  If g is omitted, its taken from the published definition for the curve.

And by the way - I *didn't* hear you suggest "security through obscurity" did I???? :-) 

Mike


At 02:29 PM 9/23/2008, Paul Hoffman wrote:

>At 11:30 AM -0400 9/23/08, Santosh Chokhani wrote:
>>What consideration was given for the ability to specify different
>>Generator Point for named curves (such as P-256) in order to provide
>>cryptographic separation for communities of interest?
>
>There are much more secure ways to gain cryptographic separation for communities of interest than to put parseable parameters in certificates. For example, using specified-curve OIDs from a private registry is much more effective because a validator cannot determine the curve parameters and use them when validating the certificate.
>
>
>--Paul Hoffman, Director
>--VPN Consortium




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m8NK7PjE095839 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Sep 2008 13:07:25 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8NK7PeM095838; Tue, 23 Sep 2008 13:07:25 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m8NK7Olv095832 for <[e-mail]>; Tue, 23 Sep 2008 13:07:24 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 1831 invoked from network); 23 Sep 2008 19:54:34 -0000
Received: from [e-mail] by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;23 Sep 2008 19:54:34 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 23 Sep 2008 19:54:34 -0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: Comments on draft-ietf-pkix-ecc-subpubkeyinfo-08
Date: Tue, 23 Sep 2008 16:07:23 -0400
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Comments on draft-ietf-pkix-ecc-subpubkeyinfo-08
Thread-Index: Ackdt/28XEFhtuEyTTGM8l+XRbRh1g==
From: "Carl Wallace" <[e-mail]>
To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Below are a few comments, nits and questions regarding
draft-ietf-pkix-ecc-subpubkeyinfo-08:

- In section 2.1.1, why is implicitCurve not deprecated along with
specifiedCurve?  The text states that implicitCurve is only supported
when namedCurve is not used and there is no option other than namedCurve
available.
- Why is A.2 the informative module?  Most sections in the spec
reference definitions from A.2. =20
- Given the amount of repetition between the ASN.1 modules, it may make
more sense to define all of the structures and OIDs once and import them
into one module that uses information objects and one that doesn't.  I
think ECParameters is the only structure that would need to go in the
module that doesn't use information objects.

- Expand EC in third paragraph of section 1
- "algorithms" should be singular in the first sentence of section 2.1
- Provide a reference to 5280 where SubjectPublicKeyInfo is defined in
Section 2
- In 2.1.2, change "fall in to different" to "fall in two different" or
"fall into different"
- Rewrite last sentence of section 3 to remove the condition since the
certificate MUST assert keyAgreement or make the statement about
asserting encipherOnly or decipherOnly one time instead of once per
certificate type.
- In Security Considerations, change "desired have value" to "desired
hash value"
- In second paragraph of section 5, "implementations" should be
singular.
- Where there are references to X9.62, the names of the structures
should be the same.  ECParameters and SpecifiedCurve appear as
ECDomainParameters and SpecifiedECDomain in X9.62.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m8NJ6VX3090970 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Sep 2008 12:06:31 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8NJ6Vow090969; Tue, 23 Sep 2008 12:06:31 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp105.biz.mail.re2.yahoo.com (smtp105.biz.mail.re2.yahoo.com [206.190.52.174]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m8NJ6JCZ090906 for <[e-mail]>; Tue, 23 Sep 2008 12:06:30 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 31131 invoked from network); 23 Sep 2008 19:06:19 -0000
Received: from unknown (HELO Wylie) ([e-mail]@96.241.103.66 with login) by smtp105.biz.mail.re2.yahoo.com with SMTP; 23 Sep 2008 19:06:18 -0000
X-YMail-OSG: .7Z4_rkVM1lR4AAwtE1sfQIAy8Yg6HlE4qJOuI7Pe6U5OJAZVz.pgK7bPkZQVXPtyPPZ_n68VaodYBk0bmyMRmKXBiVAu0Nfy93rHegQ0Ixxs7JixbaCc5EA0VTIvL0oBdfg9e4B1OLNinyHoLqmkjSYKMeVPnmfOO5gTkbP3CF7Enz0wNE-
X-Yahoo-Newman-Property: ymail-3
From: "Turner, Sean P." <[e-mail]>
To: "'Russ Housley'" <[e-mail]>, "'Santosh Chokhani'" <[e-mail]>, <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Subject: RE: I-D ACTION:draft-ietf-pkix-ecc-subpubkeyinfo-08.txt 
Date: Tue, 23 Sep 2008 15:06:16 -0400
Organization: IECA, Inc.
Message-ID: <FD66FBAEB6BF478E83473130A83BEF8D@Wylie>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
Thread-Index: Ackdrmma+D0luZsKTF2aT56vLZMOHwAAM9VA
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The document contains the following note:

  -- Note that [FIPS186-3] refers to secp192r1 as P-192, secp224r1 as
  -- P-224, secp384r1 as P-384, and secp521r1 as P-521. 

P-256 is missing so I'll add it.

spt

>-----Original Message-----
>From: [e-mail] 
>[mailto:[e-mail]] On Behalf Of Russ Housley
>Sent: Tuesday, September 23, 2008 2:17 PM
>To: Santosh Chokhani; [e-mail]
>Subject: RE: I-D ACTION:draft-ietf-pkix-ecc-subpubkeyinfo-08.txt 
>
>
>First, secp256r1and secp384r1are also known as P-256 and 
>P-384, respectively.  I guess this could be highlighted.
>
>Second, during the discussion on this list it was suggested 
>that a very reasonable way to handle such a situation was to 
>name the new curve.  That is, assign an OID.
>
>Russ
>
>
>At 11:30 AM 9/23/2008, Santosh Chokhani wrote:
>
>>What consideration was given for the ability to specify different 
>>Generator Point for named curves (such as P-256) in order to provide 
>>cryptographic separation for communities of interest?
>>
>>-----Original Message-----
>>From: [e-mail] 
>>[mailto:[e-mail]]
>>On Behalf Of [e-mail]
>>Sent: Monday, September 22, 2008 7:15 PM
>>To: [e-mail]
>>Cc: [e-mail]
>>Subject: I-D ACTION:draft-ietf-pkix-ecc-subpubkeyinfo-08.txt
>>
>>A New Internet-Draft is available from the on-line Internet-Drafts 
>>directories.
>>This draft is a work item of the Public-Key Infrastructure (X.509) 
>>Working Group of the IETF.
>>
>>         Title           : Elliptic Curve Cryptography 
>Subject Public Key
>>Information
>>         Author(s)       : S. Turner, K. Yiu, D. Brown, R. Housley, W.
>>Polk
>>         Filename        : draft-ietf-pkix-ecc-subpubkeyinfo-08.txt
>>         Pages           : 35
>>         Date            : 2008-9-22
>>
>>This document specifies the syntax and semantics for the Subject
>>    Public Key Information field in certificates that support Elliptic
>>    Curve Cryptography.  This document updates Sections 
>2.3.5, 3, and 5
>>    of RFC 3279.
>>
>>A URL for this Internet-Draft is:
>>http://www.ietf.org/internet-drafts/draft-ietf-pkix-ecc-subpub
>keyinfo-0
>>8
>>.txt
>>
>>Internet-Drafts are also available by anonymous FTP at:
>>ftp://ftp.ietf.org/internet-drafts/
>>
>>Below is the data which will enable a MIME compliant mail reader 
>>implementation to automatically retrieve the ASCII version of the 
>>Internet-Draft.
>



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m8NIbn93088515 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Sep 2008 11:37:49 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8NIbmhH088514; Tue, 23 Sep 2008 11:37:48 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m8NIbbB4088481 for <[e-mail]>; Tue, 23 Sep 2008 11:37:48 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 1018 invoked from network); 23 Sep 2008 18:24:47 -0000
Received: from [e-mail] by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;23 Sep 2008 18:24:47 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 23 Sep 2008 18:24:47 -0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: I-D ACTION:draft-ietf-pkix-ecc-subpubkeyinfo-08.txt 
Date: Tue, 23 Sep 2008 14:37:36 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: I-D ACTION:draft-ietf-pkix-ecc-subpubkeyinfo-08.txt 
Thread-Index: AckdqzMy1YTPcquQQMu2rpgcHcHqHwAADwpA
References: <[e-mail]> <[e-mail]> <[e-mail]>
From: "Santosh Chokhani" <[e-mail]>
To: "Russ Housley" <[e-mail]>, <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Russ,

Thanks.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Russ Housley
Sent: Tuesday, September 23, 2008 2:17 PM
To: Santosh Chokhani; [e-mail]
Subject: RE: I-D ACTION:draft-ietf-pkix-ecc-subpubkeyinfo-08.txt=20


First, secp256r1and secp384r1are also known as P-256 and P-384,=20
respectively.  I guess this could be highlighted.

Second, during the discussion on this list it was suggested that a=20
very reasonable way to handle such a situation was to name the new=20
curve.  That is, assign an OID.

Russ


At 11:30 AM 9/23/2008, Santosh Chokhani wrote:

>What consideration was given for the ability to specify different
>Generator Point for named curves (such as P-256) in order to provide
>cryptographic separation for communities of interest?
>
>-----Original Message-----
>From: [e-mail]
[mailto:[e-mail]]
>On Behalf Of [e-mail]
>Sent: Monday, September 22, 2008 7:15 PM
>To: [e-mail]
>Cc: [e-mail]
>Subject: I-D ACTION:draft-ietf-pkix-ecc-subpubkeyinfo-08.txt
>
>A New Internet-Draft is available from the on-line Internet-Drafts
>directories.
>This draft is a work item of the Public-Key Infrastructure (X.509)
>Working Group of the IETF.
>
>         Title           : Elliptic Curve Cryptography Subject Public
Key
>Information
>         Author(s)       : S. Turner, K. Yiu, D. Brown, R. Housley, W.
>Polk
>         Filename        : draft-ietf-pkix-ecc-subpubkeyinfo-08.txt
>         Pages           : 35
>         Date            : 2008-9-22
>
>This document specifies the syntax and semantics for the Subject
>    Public Key Information field in certificates that support Elliptic
>    Curve Cryptography.  This document updates Sections 2.3.5, 3, and 5
>    of RFC 3279.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-pkix-ecc-subpubkeyinfo-0
8
>.txt
>
>Internet-Drafts are also available by anonymous FTP at:
>ftp://ftp.ietf.org/internet-drafts/
>
>Below is the data which will enable a MIME compliant mail reader
>implementation to automatically retrieve the ASCII version of the
>Internet-Draft.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m8NITHKu087829 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Sep 2008 11:29:17 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8NITHdm087828; Tue, 23 Sep 2008 11:29:17 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from [10.20.30.152] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m8NITF2h087820 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Sep 2008 11:29:16 -0700 (MST) (envelope-from [e-mail])
Mime-Version: 1.0
Message-Id: <p06240832c4fee49f6114@[10.20.30.152]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Date: Tue, 23 Sep 2008 11:29:12 -0700
To: "Santosh Chokhani" <[e-mail]>, <[e-mail]>
From: Paul Hoffman <[e-mail]>
Subject: RE: I-D ACTION:draft-ietf-pkix-ecc-subpubkeyinfo-08.txt
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 11:30 AM -0400 9/23/08, Santosh Chokhani wrote:
>What consideration was given for the ability to specify different
>Generator Point for named curves (such as P-256) in order to provide
>cryptographic separation for communities of interest?

There are much more secure ways to gain cryptographic separation for 
communities of interest than to put parseable parameters in 
certificates. For example, using specified-curve OIDs from a private 
registry is much more effective because a validator cannot determine 
the curve parameters and use them when validating the certificate.


--Paul Hoffman, Director
--VPN Consortium



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m8NIJRJA086961 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Sep 2008 11:19:27 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8NIJRcm086960; Tue, 23 Sep 2008 11:19:27 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [8.8.40.152]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m8NIJGRu086918 for <[e-mail]>; Tue, 23 Sep 2008 11:19:27 -0700 (MST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
Received: (qmail 32409 invoked by uid 0); 23 Sep 2008 18:15:48 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (72.245.120.38) by woodstock.binhost.com with SMTP; 23 Sep 2008 18:15:48 -0000
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Tue, 23 Sep 2008 14:17:25 -0400
To: "Santosh Chokhani" <[e-mail]>, <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: RE: I-D ACTION:draft-ietf-pkix-ecc-subpubkeyinfo-08.txt 
In-Reply-To: <[e-mail]. com>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

First, secp256r1and secp384r1are also known as P-256 and P-384, 
respectively.  I guess this could be highlighted.

Second, during the discussion on this list it was suggested that a 
very reasonable way to handle such a situation was to name the new 
curve.  That is, assign an OID.

Russ


At 11:30 AM 9/23/2008, Santosh Chokhani wrote:

>What consideration was given for the ability to specify different
>Generator Point for named curves (such as P-256) in order to provide
>cryptographic separation for communities of interest?
>
>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]]
>On Behalf Of [e-mail]
>Sent: Monday, September 22, 2008 7:15 PM
>To: [e-mail]
>Cc: [e-mail]
>Subject: I-D ACTION:draft-ietf-pkix-ecc-subpubkeyinfo-08.txt
>
>A New Internet-Draft is available from the on-line Internet-Drafts
>directories.
>This draft is a work item of the Public-Key Infrastructure (X.509)
>Working Group of the IETF.
>
>         Title           : Elliptic Curve Cryptography Subject Public Key
>Information
>         Author(s)       : S. Turner, K. Yiu, D. Brown, R. Housley, W.
>Polk
>         Filename        : draft-ietf-pkix-ecc-subpubkeyinfo-08.txt
>         Pages           : 35
>         Date            : 2008-9-22
>
>This document specifies the syntax and semantics for the Subject
>    Public Key Information field in certificates that support Elliptic
>    Curve Cryptography.  This document updates Sections 2.3.5, 3, and 5
>    of RFC 3279.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-pkix-ecc-subpubkeyinfo-08
>.txt
>
>Internet-Drafts are also available by anonymous FTP at:
>ftp://ftp.ietf.org/internet-drafts/
>
>Below is the data which will enable a MIME compliant mail reader
>implementation to automatically retrieve the ASCII version of the
>Internet-Draft.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m8NFUgeB071452 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Sep 2008 08:30:42 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8NFUgv6071451; Tue, 23 Sep 2008 08:30:42 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m8NFUPO7071434 for <[e-mail]>; Tue, 23 Sep 2008 08:30:41 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 32034 invoked from network); 23 Sep 2008 15:17:33 -0000
Received: from [e-mail] by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;23 Sep 2008 15:17:33 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 23 Sep 2008 15:17:33 -0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: I-D ACTION:draft-ietf-pkix-ecc-subpubkeyinfo-08.txt 
Date: Tue, 23 Sep 2008 11:30:22 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: I-D ACTION:draft-ietf-pkix-ecc-subpubkeyinfo-08.txt 
Thread-Index: AckdDLNHhONZLp2aSzCgQxuURSDkJwAhFQfQ
References: <[e-mail]>
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

What consideration was given for the ability to specify different
Generator Point for named curves (such as P-256) in order to provide
cryptographic separation for communities of interest?

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of [e-mail]
Sent: Monday, September 22, 2008 7:15 PM
To: [e-mail]
Cc: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-ecc-subpubkeyinfo-08.txt=20

A New Internet-Draft is available from the on-line Internet-Drafts=20
directories.
This draft is a work item of the Public-Key Infrastructure (X.509)
Working Group of the IETF.

	Title		: Elliptic Curve Cryptography Subject Public Key
Information
	Author(s)	: S. Turner, K. Yiu, D. Brown, R. Housley, W.
Polk
	Filename	: draft-ietf-pkix-ecc-subpubkeyinfo-08.txt
	Pages		: 35
	Date		: 2008-9-22
=09
This document specifies the syntax and semantics for the Subject=20
   Public Key Information field in certificates that support Elliptic=20
   Curve Cryptography.  This document updates Sections 2.3.5, 3, and 5=20
   of RFC 3279.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-ecc-subpubkeyinfo-08
.txt

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

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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m8MNG93P076921 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Sep 2008 16:16:09 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8MNG92v076918; Mon, 22 Sep 2008 16:16:09 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m8MNFw2r076889 for <[e-mail]>; Mon, 22 Sep 2008 16:16:08 -0700 (MST) (envelope-from [e-mail])
Received: by core3.amsl.com (Postfix, from userid 0) id 441043A6B3B; Mon, 22 Sep 2008 16:15:01 -0700 (PDT)
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-ecc-subpubkeyinfo-08.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Mon, 22 Sep 2008 16:15:01 -0700 (PDT)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.

	Title		: Elliptic Curve Cryptography Subject Public Key Information
	Author(s)	: S. Turner, K. Yiu, D. Brown, R. Housley, W. Polk
	Filename	: draft-ietf-pkix-ecc-subpubkeyinfo-08.txt
	Pages		: 35
	Date		: 2008-9-22
	
This document specifies the syntax and semantics for the Subject 
   Public Key Information field in certificates that support Elliptic 
   Curve Cryptography.  This document updates Sections 2.3.5, 3, and 5 
   of RFC 3279.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-ecc-subpubkeyinfo-08.txt

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

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

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-pkix-ecc-subpubkeyinfo-08.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--NextPart--



Received: from [78.16.134.177] ([193.203.134.12]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m8LG5rh1034430 for <[e-mail]>; Sun, 21 Sep 2008 09:05:54 -0700 (MST) (envelope-from [e-mail])
Message-ID: <[e-mail]>
Date: Sun, 21 Sep 2008 17:05:57 +0100
Subject: ladies say size doesnot matter, but we know, it does!
From: Guy <[e-mail]>
To: [e-mail]
User-Agent: SquirrelMail/1.4.12
MIME-Version: 1.0
Content-Type: text/html;charset=utf-8
Content-Transfer-Encoding: 8bit
X-Confirm-Reading-To: <[e-mail]>
Disposition-Notification-To: <[e-mail]>
X-Priority: 3 (Normal)
Importance: Normal

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
</head>
<body bgcolor="#ffffff" text="#000000">
<div align=center> <a href="http://www.seatspirituality.com" target="_blank">
<img src="http://www.seatspirituality.com/05.gif" border=0 alt=""></a><br>
Best offers. (c) 2008. To unsubscribe click <a href="http://www.seatspirituality.com/unsubscribe.php?mail=[e-mail]&key=91b34616da2003">here</a>
</div>
</body>
</html>


Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m8KNQZlU082500 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 20 Sep 2008 16:26:35 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8KNQZUY082499; Sat, 20 Sep 2008 16:26:35 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from [10.20.30.152] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m8KNQXOx082489 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Sat, 20 Sep 2008 16:26:34 -0700 (MST) (envelope-from [e-mail])
Mime-Version: 1.0
Message-Id: <p06240809c4fb37048c8a@[10.20.30.152]>
In-Reply-To: <057201c91b5b$f526bba0$df7432e0$@com>
References: <057201c91b5b$f526bba0$df7432e0$@com>
Date: Sat, 20 Sep 2008 16:26:32 -0700
To: [e-mail]
From: Paul Hoffman <[e-mail]>
Subject: Re: Possible Errata on RFC 2560
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>Section 4.4.1 says
>
>4.4.1  Nonce
>
>    The nonce cryptographically binds a request and a response to prevent
>    replay attacks. The nonce is included as one of the requestExtensions
>    in requests, while in responses it would be included as one of the
>    responseExtensions. In both the request and the response, the nonce
>    will be identified by the object identifier id-pkix-ocsp-nonce, while
>    the extnValue is the value of the nonce.
>
>    id-pkix-ocsp-nonce     OBJECT IDENTIFIER ::= { id-pkix-ocsp 2 }
>
>
>This does not tell me the ASN.1 type of the nonce.  I assume, but do not
>know for sure that it is suppose to be an OCTET STRING.

This looks like a reasonable erratum to me.

--Paul Hoffman, Director
--VPN Consortium



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m8KK3jmw067046 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 20 Sep 2008 13:03:45 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8KK3ixY067045; Sat, 20 Sep 2008 13:03:44 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m8KK3Xb0067033 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <[e-mail]>; Sat, 20 Sep 2008 13:03:44 -0700 (MST) (envelope-from [e-mail])
Received: from GALATIONS (unknown [207.202.179.27]) by smtp1.pacifier.net (Postfix) with ESMTP id E380F6F2A9 for <[e-mail]>; Sat, 20 Sep 2008 13:03:32 -0700 (PDT)
From: "Jim Schaad" <[e-mail]>
To: <[e-mail]>
Subject: Possible Errata on RFC 2560
Date: Sat, 20 Sep 2008 13:03:31 -0700
Message-ID: <057201c91b5b$f526bba0$df7432e0$@com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AckbW/RzR8S53zNjTkecdFM1WRT43A==
Content-Language: en-us
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Section 4.4.1 says

4.4.1  Nonce

   The nonce cryptographically binds a request and a response to prevent
   replay attacks. The nonce is included as one of the requestExtensions
   in requests, while in responses it would be included as one of the
   responseExtensions. In both the request and the response, the nonce
   will be identified by the object identifier id-pkix-ocsp-nonce, while
   the extnValue is the value of the nonce.

   id-pkix-ocsp-nonce     OBJECT IDENTIFIER ::= { id-pkix-ocsp 2 }


This does not tell me the ASN.1 type of the nonce.  I assume, but do not
know for sure that it is suppose to be an OCTET STRING.


Jim Schaad




Received: from host27.190-226-150.telecom.net.ar (host27.190-226-150.telecom.net.ar [190.226.150.27]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m8K2r2wx009180 for <[e-mail]>; Fri, 19 Sep 2008 19:53:04 -0700 (MST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
Date:   Fri, 19 Sep 2008 23:53:05 -0300
From:   tid <[e-mail]>
User-Agent: Thunderbird 2.0.0.16 (Windows/20080708)
MIME-Version: 1.0
To: [e-mail]
Subject: Secret to young-looking skin.
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
</head>
<body bgcolor="#ffffff" text="#000000">
<div align=center> <a href="http://www.spreadsuggest.com" target="_blank">
<img src="http://www.spreadsuggest.com/05.gif" border=0 alt=""></a> </div><br>
</body>
</html>


Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m8JKGBLL080856 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Sep 2008 13:16:11 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8JKGB0b080855; Fri, 19 Sep 2008 13:16:11 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [8.8.40.152]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m8JKFxuQ080845 for <[e-mail]>; Fri, 19 Sep 2008 13:16:10 -0700 (MST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
Received: (qmail 9483 invoked by uid 0); 19 Sep 2008 20:13:26 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (96.255.143.50) by woodstock.binhost.com with SMTP; 19 Sep 2008 20:13:26 -0000
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Fri, 19 Sep 2008 16:15:54 -0400
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: Question about implementation of name constraints
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

First I want to provide some background from RFC 5280, then I have a 
three-part question for implementors.

In Section 4.2, we learn that the name constraints extension MUST be 
recognized:

     At a minimum, applications conforming to this profile MUST recognize
    the following extensions: key usage (Section 4.2.1.3), certificate
    policies (Section 4.2.1.4), subject alternative name (Section
    4.2.1.6), basic constraints (Section 4.2.1.9), name constraints
    (Section 4.2.1.10), policy constraints (Section 4.2.1.11), extended
    key usage (Section 4.2.1.12), and inhibit anyPolicy (Section
    4.2.1.14).

Then, in Section 4.2.1.10 we learn that the name constraints 
extension MUST only appear in CA certificates and that the 
constraints apply to both the subject name and the subject alt name:

    The name constraints extension, which MUST be used only in a CA
    certificate, indicates a name space within which all subject names in
    subsequent certificates in a certification path MUST be located.
    Restrictions apply to the subject distinguished name and apply to
    subject alternative names.  Restrictions apply only when the
    specified name form is present.  If no name of the type is in the
    certificate, the certificate is acceptable.

We also learn that the name constraints extension MUST be critical:

    ... Conforming CAs MUST mark this extension as
    critical and SHOULD NOT impose name constraints on the x400Address,
    ediPartyName, or registeredID name forms. ...

Section 4.2.1.10 also has some requirements for applications that use 
the certificate:

    Applications conforming to this profile MUST be able to process name
    constraints that are imposed on the directoryName name form and
    SHOULD be able to process name constraints that are imposed on the
    rfc822Name, uniformResourceIdentifier, dNSName, and iPAddress name
    forms.  If a name constraints extension that is marked as critical
    imposes constraints on a particular name form, and an instance of
    that name form appears in the subject field or subjectAltName
    extension of a subsequent certificate, then the application MUST
    either process the constraint or reject the certificate.

So, now my question to implementors.  I'm trying to find out what 
will really happen if a CA tries to use name constraints to constrain 
a domain name.

If your implementation encounters a certification path where one or 
more of the CA certificates includes a critical name constraints 
extension, will the implementation accept the certification path or 
reject it when:

(a) the directoryName form is constrained using the domainComponent attribute?

(b) the dNSName form is constrained?

(c) the uniformResourceIdentifier is constrained to a particular domain name?

For (b) and (c), I'm assuming the  following parts of RFC 5280 are followed:

    For URIs, the constraint applies to the host part of the name.  The
    constraint MUST be specified as a fully qualified domain name and MAY
    specify a host or a domain.  Examples would be "host.example.com" and
    ".example.com".  When the constraint begins with a period, it MAY be
    expanded with one or more labels.  That is, the constraint
    ".example.com" is satisfied by both host.example.com and
    my.host.example.com.  However, the constraint ".example.com" is not
    satisfied by "example.com".  When the constraint does not begin with
    a period, it specifies a host.  If a constraint is applied to the
    uniformResourceIdentifier name form and a subsequent certificate
    includes a subjectAltName extension with a uniformResourceIdentifier
    that does not include an authority component with a host name
    specified as a fully qualified domain name (e.g., if the URI either
    does not include an authority component or includes an authority
    component in which the host name is specified as an IP address), then
    the application MUST reject the certificate.

    DNS name restrictions are expressed as host.example.com.  Any DNS
    name that can be constructed by simply adding zero or more labels to
    the left-hand side of the name satisfies the name constraint.  For
    example, www.host.example.com would satisfy the constraint but
    host1.example.com would not.

Thanks for your help in advance,
   Russ



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m8JJvW3X079518 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Sep 2008 12:57:32 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8JJvW7N079517; Fri, 19 Sep 2008 12:57:32 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from pne-smtpout1-sn1.fre.skanova.net (pne-smtpout1-sn1.fre.skanova.net [81.228.11.98]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m8JJvKYG079496 for <[e-mail]>; Fri, 19 Sep 2008 12:57:31 -0700 (MST) (envelope-from [e-mail])
Received: from arport2v (81.232.45.215) by pne-smtpout1-sn1.fre.skanova.net (7.3.129) (authenticated as u18116613) id 47A9795003C6E612 for [e-mail]; Fri, 19 Sep 2008 21:57:20 +0200
Message-ID: <034901c91a91$ecee2560$82c5a8c0@arport2v>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>
References: <00d401c91a2b$a5159220$82c5a8c0@arport2v>
Subject: Clarification: Subject Key Attestation Evidence "light" - Invention Disclosure
Date: Fri, 19 Sep 2008 21:57:18 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1933
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1933
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"to thwart possible future IPR claims" includes myself as well:-)
I.e. this is intended to be in the public domain since it is a
part an Open Source project.
----- Original Message ----- 
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>
Sent: Friday, September 19, 2008 09:45
Subject: Subject Key Attestation Evidence "light" - Invention Disclosure



The following may be prior art, or be common knowledge. It may
even be a bad idea.  However, the publishing was only done
in order to thwart possible future IPR claims.  If the principle
is already patented, I would appreciate more information
if possible.  The concept described is primarily intended for usage
with mobile phones having embedded crypto hardware which should
be the majority within 5-10 years from now, since crypto hardware is
close to a requirement for making secure operating systems.
In case you find the mail version hard to read, there is a PDF with
the same content available:
http://webpki.org/papers/keygen2/SubjectKeyAttestationEvidence-light__InventionDisclosure.pdf

The decribed scheme is an intrinsic part of the KeyGen2 universal
key-provisioning protocol:
http://webpki.org/papers/keygen2/keygen2-key-attestation-1.pdf

SKAE "light" - Invention Disclosure
------------------------------------

Background
=========

In some cryptographic systems, asymmetric key-pairs may be
internally generated in Security Elements (SEs), like Smart Cards.
For on-line (remote) provisioning of keys to SEs, there is a whish
by CAs to be able to securely verify that the public key part
they receive for inclusion in a certificate, indeed was (together
with its private counterpart), generated inside of a "genuine" SE.

To support this requirement the TrustedComputingGroup's (TCG's)
Trusted Platform Module (TPM) V1.2 specification features a
mechanism known as Subject Key Attestation Evidence (SKAE).

Prerequisite: The SE contains an embedded private key and a
matching public key certificate identifying the SE in some way that
makes sense for CAs.  The private key is used for signing evidence
attestations regarding generated key-pairs.

Problem: If the embedded private key of the SE is also to be usable
for other cryptographic operations, a "hacked" software environment
could exploit this by creating unprotected key-pairs externally and
still be able providing CAs with genuine-looking attestation
evidences.  TCG's solution to this problem is based on the use
of dedicated key attest keys, specific X.509 certificate extensions,
and potentially also relying on multiple CA roots.  Although
working, this scheme appears unnecessary complex for supporting
a single-purpose key.

Solution
======

The following steps describe how a simpler form of SKAE,
purely based on cryptography, could be implemented in an SE.

First you need to restrict the SE key-certifying private key from being
able to perform unformatted ("blank") RSA decryption
operations through direct API calls to the SE.

You MAY still allow the key-certifying key creating standard
PKCS #1 signatures which are useful for many purposes including
authentication and message integrity.  Encryption operations using
the public key MAY also be supported.

To support SKAE, the proposal is to create a unique variant of PKCS #1
signatures that must only be generated during key-generation.
Such a signature MAY also be created if the SE is explicitly invoked with
a previously generated public key, unless that would lead
to key-reuse vulnerabilities.

A unique variant of PKCS #1 could in its simplest form be implemented
through the use of a non-standard padding pattern.  The hash
algorithms to use would still be the existing SHA-1 etc.  A verifier
should then be able to securely distinguish between standard
signatures and SKAE signatures.  A nonce option would also be
suitable for inclusion in the signature packet.   On the next pages,
there is a sample program in Java implementing the proposed
SKAE scheme.

Although this scheme only describes PKCS #1 (RSA) keys, the
principles are presumable applicable to other asymmetric key types as
well including ECDSA.

One might consider the proposed solution as a standards-defying
"kludge", but the fact is that all current SKAE schemes rely on very
specific generation and validation code.

The primary target for this invention are mobile phones which are
likely to be fitted with secure hardware fairly soon, since this
is more or less a requirement for other purposes as well, most
notably for Operating System integrity protection.

Side Effect: PoP Becomes Redundant
==========================

It seems that a properly designed SKAE scheme makes
Proof of Possession (PoP) signatures like in CRMF (RFC 4211)
redundant which is an advantage because combining PoP
signatures with PIN-code provisioning introduces fairly
awkward state-handling in SEs since the generated private
key typically must be used before it is fully provisioned.

Anders Rundgren, WebPKI.org, September 15, 2008

Author's address:
Storbolsäng 50
740 10 Almunge
Sweden

Email: [e-mail]

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


import javax.crypto.Cipher;

import java.security.GeneralSecurityException;
import java.security.MessageDigest;
import java.security.PublicKey;
import java.security.PrivateKey;
import java.security.KeyPair;
import java.security.KeyPairGenerator;

import java.security.interfaces.RSAKey;

/**
 * SKAE (Subject Key Attestation Evidence).  The following J2SE compatible code is meant illustrate
 * the use of SKAE signatures.
 */
public class skae
  {
    static final String SHA_1            = "SHA-1";

    static final String UNFORMATTED_RSA  = "RSA/ECB/NoPadding";

    static final byte[] PS_END_SEQUENCE  = new byte[] {(byte)0x00, (byte)'S',  (byte)'K',  (byte)'A',  (byte)'E'};

    static final byte[] DIGEST_INFO_SHA1 = new byte[] {(byte)0x30, (byte)0x21, (byte)0x30, (byte)0x09, (byte)0x06,
                                                       (byte)0x05, (byte)0x2b, (byte)0x0e, (byte)0x03, (byte)0x02,
                                                       (byte)0x1a, (byte)0x05, (byte)0x00, (byte)0x04, (byte)0x14};


    /**
     * Create an SKAE package for signing or verification
     * @param rsa_key The certifying (attesting) private or public key.
     * @param certified_public_key The certified (attested) key.
     * @param optional_nonce An optional "nonce" element.
     * @return The SKAE package.
     */
    public static byte[] createSKAEPackage (RSAKey rsa_key,
                                            PublicKey certified_public_key,
                                            byte[] optional_nonce)
    throws GeneralSecurityException
      {
        ////////////////////////////////////////////////////////////////////////////////////////
        // To make it feasible securely distinguishing standard RSASSA-PKCS1.5 signatures     //
        // from SKAE signatures the latter are packaged in a different way which should       //
        // create errors if processed by a crypto library that does not support SKAE.         //
        // The following shows the packaging differences in detail.                           //
        //                                                                                    //
        // EMSA-PKCS1-v1_5: EM = 0x00 || 0x01 || PS || 0x00 || T                              //
        //                                                                                    //
        // EM-PKCS1-SKAE:   EM = 0x00 || 0x01 || PS || 0x00 || 'S' || 'K' || 'A' || 'E' || T  //
        ////////////////////////////////////////////////////////////////////////////////////////
        byte[] modulus = rsa_key.getModulus ().toByteArray ();
        int k = modulus.length;
        if (modulus[0] == 0) k--;
        byte[] encoded_message = new byte [k];
        encoded_message[0] = (byte)0;
        encoded_message[1] = (byte)1;
        MessageDigest md = MessageDigest.getInstance (SHA_1);
        if (optional_nonce != null)
          {
            md.update (optional_nonce);
          }
        byte[] hash = md.digest (certified_public_key.getEncoded ());
        int i = k - 2 - PS_END_SEQUENCE.length - hash.length - DIGEST_INFO_SHA1.length;
        int j = 2;
        while (i-- > 0)
          {
            encoded_message[j++] = (byte)0xff;
          }
        i = 0;
        while (i < PS_END_SEQUENCE.length)
          {
            encoded_message[j++] = PS_END_SEQUENCE[i++];
          }
        System.arraycopy (DIGEST_INFO_SHA1, 0, encoded_message, j, DIGEST_INFO_SHA1.length);
        System.arraycopy (hash, 0, encoded_message, j + DIGEST_INFO_SHA1.length, hash.length);
        return encoded_message;
      }



   /**
     * Verify an SKAE signature
     * @param skae_signature The signature to be verified.
     * @param certifying_public_key The certifying (attesting) public key.
     * @param certified_public_key The certified (attested) key.
     * @param optional_nonce An optional "nonce" element.
     * @throws GeneralSecurityException if the signature is invalid or indata is incorrect.
     */
    public static void verifySKAESignature (byte[] skae_signature,
                                            PublicKey certifying_public_key,
                                            PublicKey certified_public_key,
                                            byte[] optional_nonce)
    throws GeneralSecurityException
      {
        Cipher cipher = Cipher.getInstance (UNFORMATTED_RSA);
        cipher.init (Cipher.ENCRYPT_MODE, certifying_public_key);
        byte[] received_signature_package = cipher.doFinal (skae_signature);
        byte[] reference_signature_package = createSKAEPackage ((RSAKey)certifying_public_key,
                                                                certified_public_key,
                                                                optional_nonce);
        if (reference_signature_package.length != received_signature_package.length)
          {
            throw new GeneralSecurityException ("Signature package length error");
          }
        for (int i = 0; i < received_signature_package.length ; i++)
          {
            if (received_signature_package[i] != reference_signature_package[i])
              {
                // A more comprehensive diagnostic would be preferable...
                throw new GeneralSecurityException ("Signature package content error");
              }
          }
      }


    public static class GeneratedKey
      {
        PublicKey certified_public_key;
        PublicKey certifying_public_key;
        byte[] skae_signature;
      }


    public static class SecurityElement
      {
        PublicKey certifying_public_key;

        private PrivateKey certifying_private_key;

        public SecurityElement () throws GeneralSecurityException
          {
            /////////////////////////////////////////////////////////////////
            // Key-certifying keys are typically created once during       //
            // device manufacturing. The public key part is also most      //
            // likely distributed in an X.509 certificate issued by a CA   //
            // setup specifically for certifying crypto hardware.          //
            // That is, the following lines are just for showing the       //
            // cryptography, without any infrastructural considerations.   //
            /////////////////////////////////////////////////////////////////
            KeyPairGenerator certifier = KeyPairGenerator.getInstance ("RSA");
            certifier.initialize (2048);
            KeyPair certifying_key_pair = certifier.generateKeyPair ();
            certifying_public_key = certifying_key_pair.getPublic ();
            certifying_private_key = certifying_key_pair.getPrivate ();
          }


        /**
         * Create a certified key-pair.
         * @param size The size of the RSA key.
         * @param optional_nonce An optional "nonce" element.
         * @return A container with a generated public key and attesting signature.
         */
        public GeneratedKey generateCertifiedKeyPair (int size, byte[] optional_nonce)
        throws GeneralSecurityException
          {
            /////////////////////////////////////////////////////////////////
            // Generate a new key-pair in the Security Element.  The       //
            // private key is presumably stored securely in hardware and   //
            // never leave its container, unless "sealed" by the latter.   //
            /////////////////////////////////////////////////////////////////
            KeyPairGenerator kpg = KeyPairGenerator.getInstance ("RSA");
            kpg.initialize (size);
            KeyPair new_key_pair = kpg.generateKeyPair ();

            /////////////////////////////////////////////////////////////////
            // Now let the Security Element attest that the new key-pair   //
            // actually was created inside of the Security Element.        //
            //                                                             //
            // NOTE 1: The Security Element MUST NOT expose an API that    //
            // allows unformatted RSA decryptions like used below to be    //
            // performed with the key-certifying key, otherwise "malware"  //
            // could easily create fake attestations for any externally    //
            // supplied key-pair!                                          //
            //                                                             //
            // NOTE 2: Due to the fact that SKAE signatures are only to    //
            // be created for generated keys, the key-certifying key MAY   //
            // also be used for creating ordinary PKCS1.5 signatures for   //
            // things like authentications and securing message integrity  //
            /////////////////////////////////////////////////////////////////
            GeneratedKey gk = new GeneratedKey ();
            gk.certified_public_key = new_key_pair.getPublic ();
            Cipher cipher = Cipher.getInstance (UNFORMATTED_RSA);
            cipher.init (Cipher.DECRYPT_MODE, certifying_private_key);
            gk.skae_signature = cipher.doFinal (createSKAEPackage ((RSAKey)certifying_private_key,
                                                                   gk.certified_public_key,
                                                                   optional_nonce));
            gk.certifying_public_key = certifying_public_key;
            return gk;
          }
      }


    public static void main (String[] args) throws Exception
      {

        /////////////////////////////////////////////////////////////////
        //                                                             //
        //                     CLIENT Operations                       //
        //                                                             //
        // It is assumed that the critical operations are performed    //
        // inside of the Security Element, otherwise attestations      //
        // would not be more trustworthy than the environment where    //
        // the Security Element is actually running in!                //
        /////////////////////////////////////////////////////////////////
        SecurityElement se = new SecurityElement ();

        /////////////////////////////////////////////////////////////////
        // Generate a new key-pair in the Security Element.  The       //
        // private key is presumably stored securely in hardware and   //
        // never leave its container, unless "sealed" by the latter.   //
        /////////////////////////////////////////////////////////////////
        byte[] nonce = null; // Didn't use a nonce in the sample run
        GeneratedKey gk = se.generateCertifiedKeyPair (1024, nonce);

        /////////////////////////////////////////////////////////////////
        //                                                             //
        //                     VERIFIER Operations                     //
        //                                                             //
        // The certifying public key is supposed to be transferred to  //
        // the verifier by some kind of protocol, together with the    //
        // SKAE-signature, certified public key, and the optional      //
        // nonce.  A nonce (if used) would preferably be created by    //
        // the verifier during an earlier (not shown) protocol phase.  //
        /////////////////////////////////////////////////////////////////
        verifySKAESignature (gk.skae_signature,
                             gk.certifying_public_key,
                             gk.certified_public_key,
                             nonce);

        System.out.println ("The SKAE signature appears to be valid!");
      }

  }



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m8J7jNu0031076 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Sep 2008 00:45:23 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8J7jN2W031075; Fri, 19 Sep 2008 00:45:23 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from pne-smtpout1-sn1.fre.skanova.net (pne-smtpout1-sn1.fre.skanova.net [81.228.11.98]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m8J7jBVn031065 for <[e-mail]>; Fri, 19 Sep 2008 00:45:22 -0700 (MST) (envelope-from [e-mail])
Received: from arport2v (81.232.45.215) by pne-smtpout1-sn1.fre.skanova.net (7.3.129) (authenticated as u18116613) id 47A9795003C3BD96 for [e-mail]; Fri, 19 Sep 2008 09:45:11 +0200
Message-ID: <00d401c91a2b$a5159220$82c5a8c0@arport2v>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>
Subject: Subject Key Attestation Evidence "light" - Invention Disclosure
Date: Fri, 19 Sep 2008 09:45:10 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1933
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1933
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The following may be prior art, or be common knowledge. It may
even be a bad idea.  However, the publishing was only done
in order to thwart possible future IPR claims.  If the principle
is already patented, I would appreciate more information
if possible.  The concept described is primarily intended for usage
with mobile phones having embedded crypto hardware which should
be the majority within 5-10 years from now, since crypto hardware is
close to a requirement for making secure operating systems.
In case you find the mail version hard to read, there is a PDF with
the same content available:
http://webpki.org/papers/keygen2/SubjectKeyAttestationEvidence-light__InventionDisclosure.pdf

The decribed scheme is an intrinsic part of the KeyGen2 universal
key-provisioning protocol:
http://webpki.org/papers/keygen2/keygen2-key-attestation-1.pdf

SKAE "light" - Invention Disclosure
------------------------------------

Background
=========

In some cryptographic systems, asymmetric key-pairs may be
internally generated in Security Elements (SEs), like Smart Cards.
For on-line (remote) provisioning of keys to SEs, there is a whish
by CAs to be able to securely verify that the public key part
they receive for inclusion in a certificate, indeed was (together
with its private counterpart), generated inside of a "genuine" SE.

To support this requirement the TrustedComputingGroup's (TCG's)
Trusted Platform Module (TPM) V1.2 specification features a
mechanism known as Subject Key Attestation Evidence (SKAE).

Prerequisite: The SE contains an embedded private key and a
matching public key certificate identifying the SE in some way that
makes sense for CAs.  The private key is used for signing evidence
attestations regarding generated key-pairs.

Problem: If the embedded private key of the SE is also to be usable
for other cryptographic operations, a "hacked" software environment
could exploit this by creating unprotected key-pairs externally and
still be able providing CAs with genuine-looking attestation
evidences.  TCG's solution to this problem is based on the use
of dedicated key attest keys, specific X.509 certificate extensions,
and potentially also relying on multiple CA roots.  Although
working, this scheme appears unnecessary complex for supporting
a single-purpose key.

Solution
======

The following steps describe how a simpler form of SKAE,
purely based on cryptography, could be implemented in an SE.

First you need to restrict the SE key-certifying private key from being
able to perform unformatted ("blank") RSA decryption
operations through direct API calls to the SE.

You MAY still allow the key-certifying key creating standard
PKCS #1 signatures which are useful for many purposes including
authentication and message integrity.  Encryption operations using
the public key MAY also be supported.

To support SKAE, the proposal is to create a unique variant of PKCS #1
signatures that must only be generated during key-generation.
Such a signature MAY also be created if the SE is explicitly invoked with
a previously generated public key, unless that would lead
to key-reuse vulnerabilities.

A unique variant of PKCS #1 could in its simplest form be implemented
through the use of a non-standard padding pattern.  The hash
algorithms to use would still be the existing SHA-1 etc.  A verifier
should then be able to securely distinguish between standard
signatures and SKAE signatures.  A nonce option would also be
suitable for inclusion in the signature packet.   On the next pages,
there is a sample program in Java implementing the proposed
SKAE scheme.

Although this scheme only describes PKCS #1 (RSA) keys, the
principles are presumable applicable to other asymmetric key types as
well including ECDSA.

One might consider the proposed solution as a standards-defying
"kludge", but the fact is that all current SKAE schemes rely on very
specific generation and validation code.

The primary target for this invention are mobile phones which are
likely to be fitted with secure hardware fairly soon, since this
is more or less a requirement for other purposes as well, most
notably for Operating System integrity protection.

Side Effect: PoP Becomes Redundant
==========================

It seems that a properly designed SKAE scheme makes
Proof of Possession (PoP) signatures like in CRMF (RFC 4211)
redundant which is an advantage because combining PoP
signatures with PIN-code provisioning introduces fairly
awkward state-handling in SEs since the generated private
key typically must be used before it is fully provisioned.

Anders Rundgren, WebPKI.org, September 15, 2008

Author's address:
Storbolsäng 50
740 10 Almunge
Sweden

Email: [e-mail]

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


import javax.crypto.Cipher;

import java.security.GeneralSecurityException;
import java.security.MessageDigest;
import java.security.PublicKey;
import java.security.PrivateKey;
import java.security.KeyPair;
import java.security.KeyPairGenerator;

import java.security.interfaces.RSAKey;

/**
 * SKAE (Subject Key Attestation Evidence).  The following J2SE compatible code is meant illustrate
 * the use of SKAE signatures.
 */
public class skae
  {
    static final String SHA_1            = "SHA-1";

    static final String UNFORMATTED_RSA  = "RSA/ECB/NoPadding";

    static final byte[] PS_END_SEQUENCE  = new byte[] {(byte)0x00, (byte)'S',  (byte)'K',  (byte)'A',  (byte)'E'};

    static final byte[] DIGEST_INFO_SHA1 = new byte[] {(byte)0x30, (byte)0x21, (byte)0x30, (byte)0x09, (byte)0x06,
                                                       (byte)0x05, (byte)0x2b, (byte)0x0e, (byte)0x03, (byte)0x02,
                                                       (byte)0x1a, (byte)0x05, (byte)0x00, (byte)0x04, (byte)0x14};


    /**
     * Create an SKAE package for signing or verification
     * @param rsa_key The certifying (attesting) private or public key.
     * @param certified_public_key The certified (attested) key.
     * @param optional_nonce An optional "nonce" element.
     * @return The SKAE package.
     */
    public static byte[] createSKAEPackage (RSAKey rsa_key,
                                            PublicKey certified_public_key,
                                            byte[] optional_nonce)
    throws GeneralSecurityException
      {
        ////////////////////////////////////////////////////////////////////////////////////////
        // To make it feasible securely distinguishing standard RSASSA-PKCS1.5 signatures     //
        // from SKAE signatures the latter are packaged in a different way which should       //
        // create errors if processed by a crypto library that does not support SKAE.         //
        // The following shows the packaging differences in detail.                           //
        //                                                                                    //
        // EMSA-PKCS1-v1_5: EM = 0x00 || 0x01 || PS || 0x00 || T                              //
        //                                                                                    //
        // EM-PKCS1-SKAE:   EM = 0x00 || 0x01 || PS || 0x00 || 'S' || 'K' || 'A' || 'E' || T  //
        ////////////////////////////////////////////////////////////////////////////////////////
        byte[] modulus = rsa_key.getModulus ().toByteArray ();
        int k = modulus.length;
        if (modulus[0] == 0) k--;
        byte[] encoded_message = new byte [k];
        encoded_message[0] = (byte)0;
        encoded_message[1] = (byte)1;
        MessageDigest md = MessageDigest.getInstance (SHA_1);
        if (optional_nonce != null)
          {
            md.update (optional_nonce);
          }
        byte[] hash = md.digest (certified_public_key.getEncoded ());
        int i = k - 2 - PS_END_SEQUENCE.length - hash.length - DIGEST_INFO_SHA1.length;
        int j = 2;
        while (i-- > 0)
          {
            encoded_message[j++] = (byte)0xff;
          }
        i = 0;
        while (i < PS_END_SEQUENCE.length)
          {
            encoded_message[j++] = PS_END_SEQUENCE[i++];
          }
        System.arraycopy (DIGEST_INFO_SHA1, 0, encoded_message, j, DIGEST_INFO_SHA1.length);
        System.arraycopy (hash, 0, encoded_message, j + DIGEST_INFO_SHA1.length, hash.length);
        return encoded_message;
      }



   /**
     * Verify an SKAE signature
     * @param skae_signature The signature to be verified.
     * @param certifying_public_key The certifying (attesting) public key.
     * @param certified_public_key The certified (attested) key.
     * @param optional_nonce An optional "nonce" element.
     * @throws GeneralSecurityException if the signature is invalid or indata is incorrect.
     */
    public static void verifySKAESignature (byte[] skae_signature,
                                            PublicKey certifying_public_key,
                                            PublicKey certified_public_key,
                                            byte[] optional_nonce)
    throws GeneralSecurityException
      {
        Cipher cipher = Cipher.getInstance (UNFORMATTED_RSA);
        cipher.init (Cipher.ENCRYPT_MODE, certifying_public_key);
        byte[] received_signature_package = cipher.doFinal (skae_signature);
        byte[] reference_signature_package = createSKAEPackage ((RSAKey)certifying_public_key,
                                                                certified_public_key,
                                                                optional_nonce);
        if (reference_signature_package.length != received_signature_package.length)
          {
            throw new GeneralSecurityException ("Signature package length error");
          }
        for (int i = 0; i < received_signature_package.length ; i++)
          {
            if (received_signature_package[i] != reference_signature_package[i])
              {
                // A more comprehensive diagnostic would be preferable...
                throw new GeneralSecurityException ("Signature package content error");
              }
          }
      }


    public static class GeneratedKey
      {
        PublicKey certified_public_key;
        PublicKey certifying_public_key;
        byte[] skae_signature;
      }


    public static class SecurityElement
      {
        PublicKey certifying_public_key;

        private PrivateKey certifying_private_key;

        public SecurityElement () throws GeneralSecurityException
          {
            /////////////////////////////////////////////////////////////////
            // Key-certifying keys are typically created once during       //
            // device manufacturing. The public key part is also most      //
            // likely distributed in an X.509 certificate issued by a CA   //
            // setup specifically for certifying crypto hardware.          //
            // That is, the following lines are just for showing the       //
            // cryptography, without any infrastructural considerations.   //
            /////////////////////////////////////////////////////////////////
            KeyPairGenerator certifier = KeyPairGenerator.getInstance ("RSA");
            certifier.initialize (2048);
            KeyPair certifying_key_pair = certifier.generateKeyPair ();
            certifying_public_key = certifying_key_pair.getPublic ();
            certifying_private_key = certifying_key_pair.getPrivate ();
          }


        /**
         * Create a certified key-pair.
         * @param size The size of the RSA key.
         * @param optional_nonce An optional "nonce" element.
         * @return A container with a generated public key and attesting signature.
         */
        public GeneratedKey generateCertifiedKeyPair (int size, byte[] optional_nonce)
        throws GeneralSecurityException
          {
            /////////////////////////////////////////////////////////////////
            // Generate a new key-pair in the Security Element.  The       //
            // private key is presumably stored securely in hardware and   //
            // never leave its container, unless "sealed" by the latter.   //
            /////////////////////////////////////////////////////////////////
            KeyPairGenerator kpg = KeyPairGenerator.getInstance ("RSA");
            kpg.initialize (size);
            KeyPair new_key_pair = kpg.generateKeyPair ();

            /////////////////////////////////////////////////////////////////
            // Now let the Security Element attest that the new key-pair   //
            // actually was created inside of the Security Element.        //
            //                                                             //
            // NOTE 1: The Security Element MUST NOT expose an API that    //
            // allows unformatted RSA decryptions like used below to be    //
            // performed with the key-certifying key, otherwise "malware"  //
            // could easily create fake attestations for any externally    //
            // supplied key-pair!                                          //
            //                                                             //
            // NOTE 2: Due to the fact that SKAE signatures are only to    //
            // be created for generated keys, the key-certifying key MAY   //
            // also be used for creating ordinary PKCS1.5 signatures for   //
            // things like authentications and securing message integrity  //
            /////////////////////////////////////////////////////////////////
            GeneratedKey gk = new GeneratedKey ();
            gk.certified_public_key = new_key_pair.getPublic ();
            Cipher cipher = Cipher.getInstance (UNFORMATTED_RSA);
            cipher.init (Cipher.DECRYPT_MODE, certifying_private_key);
            gk.skae_signature = cipher.doFinal (createSKAEPackage ((RSAKey)certifying_private_key,
                                                                   gk.certified_public_key,
                                                                   optional_nonce));
            gk.certifying_public_key = certifying_public_key;
            return gk;
          }
      }


    public static void main (String[] args) throws Exception
      {

        /////////////////////////////////////////////////////////////////
        //                                                             //
        //                     CLIENT Operations                       //
        //                                                             //
        // It is assumed that the critical operations are performed    //
        // inside of the Security Element, otherwise attestations      //
        // would not be more trustworthy than the environment where    //
        // the Security Element is actually running in!                //
        /////////////////////////////////////////////////////////////////
        SecurityElement se = new SecurityElement ();

        /////////////////////////////////////////////////////////////////
        // Generate a new key-pair in the Security Element.  The       //
        // private key is presumably stored securely in hardware and   //
        // never leave its container, unless "sealed" by the latter.   //
        /////////////////////////////////////////////////////////////////
        byte[] nonce = null; // Didn't use a nonce in the sample run
        GeneratedKey gk = se.generateCertifiedKeyPair (1024, nonce);

        /////////////////////////////////////////////////////////////////
        //                                                             //
        //                     VERIFIER Operations                     //
        //                                                             //
        // The certifying public key is supposed to be transferred to  //
        // the verifier by some kind of protocol, together with the    //
        // SKAE-signature, certified public key, and the optional      //
        // nonce.  A nonce (if used) would preferably be created by    //
        // the verifier during an earlier (not shown) protocol phase.  //
        /////////////////////////////////////////////////////////////////
        verifySKAESignature (gk.skae_signature,
                             gk.certifying_public_key,
                             gk.certified_public_key,
                             nonce);

        System.out.println ("The SKAE signature appears to be valid!");
      }

  }



Received: from host127-9-static.4-79-b.business.telecomitalia.it (host127-9-static.4-79-b.business.telecomitalia.it [79.4.9.127]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m8IE0sFX055847 for <[e-mail]>; Thu, 18 Sep 2008 07:00:58 -0700 (MST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
Date:   Thu, 18 Sep 2008 16:00:52 +0200
From:   duong <[e-mail]>
User-Agent: Thunderbird 2.0.0.16 (Windows/20080708)
MIME-Version: 1.0
To: [e-mail]
Subject: She will want to wrap her hands around your shaft
Content-Type: multipart/alternative; boundary="------------020308070201030802030704"

--------------020308070201030802030704
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Your rocket will now be able to shoot further and stronger
http://www.tinewaif.com/ <http://www.tinewaif.com/>

--------------020308070201030802030704
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Your rocket will now be able to shoot further and stronger<br>
<a href="http://www.tinewaif.com/">http://www.tinewaif.com/</a><br>
</body>
</html>

--------------020308070201030802030704--


Received: from [59.17.149.36] ([59.17.149.36]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m8I2Uh6t005538 for <[e-mail]>; Wed, 17 Sep 2008 19:30:49 -0700 (MST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
Date:   Thu, 18 Sep 2008 11:33:05 +0900
From:   Abbey <[e-mail]>
User-Agent: Thunderbird 2.0.0.16 (Windows/20080708)
MIME-Version: 1.0
To: [e-mail]
Subject: Make her wet and crazy
Content-Type: multipart/alternative; boundary="------------050501050801070006080601"

--------------050501050801070006080601
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

make your cock full size for full control
http://www.halodace.com/ <http://www.halodace.com/>

--------------050501050801070006080601
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
make your cock full size for full control<br>
<a href="http://www.halodace.com/">http://www.halodace.com/</a><br>
</body>
</html>

--------------050501050801070006080601--


Received: from [91.74.111.202] ([91.74.111.202]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m8HBQnKF040893 for <[e-mail]>; Wed, 17 Sep 2008 04:26:58 -0700 (MST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
Date:   Wed, 17 Sep 2008 15:27:03 +0400
From:   Tad <[e-mail]>
User-Agent: Thunderbird 2.0.0.16 (Windows/20080708)
MIME-Version: 1.0
To: [e-mail]
Subject: Re: watch miley cyrus suck off
Content-Type: multipart/alternative; boundary="------------050401050208020308050100"

--------------050401050208020308050100
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

increase her cravings for sexual fulfillment
http://www.kerofit.com/ <http://www.kerofit.com/>

--------------050401050208020308050100
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
increase her cravings for sexual fulfillment<br>
<a href="http://www.kerofit.com/">http://www.kerofit.com/</a><br>
</body>
</html>

--------------050401050208020308050100--


Received: from [211.221.40.206] ([211.221.40.206]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m8H1osCd098481 for <[e-mail]>; Tue, 16 Sep 2008 18:50:58 -0700 (MST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
Date:   Wed, 17 Sep 2008 10:50:58 +0900
From:   Jeonga <[e-mail]>
User-Agent: Thunderbird 2.0.0.16 (Windows/20080708)
MIME-Version: 1.0
To: [e-mail]
Subject: They will beg you to screw them
Content-Type: multipart/alternative; boundary="------------080708050304080702040500"

--------------080708050304080702040500
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

No more worries about premature ejaculation because the solution is here. Find out how to cure
http://www.calpdial.com/ <http://www.calpdial.com/>

--------------080708050304080702040500
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
No more worries about premature ejaculation because the solution is here. Find out how to cure<br>
<a href="http://www.calpdial.com/">http://www.calpdial.com/</a><br>
</body>
</html>

--------------080708050304080702040500--


Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m8GLUEj7078917 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Sep 2008 14:30:14 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8GLUE7W078916; Tue, 16 Sep 2008 14:30:14 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m8GLUEI8078910 for <[e-mail]>; Tue, 16 Sep 2008 14:30:14 -0700 (MST) (envelope-from [e-mail])
Received: by core3.amsl.com (Postfix, from userid 0) id A89A328C261; Tue, 16 Sep 2008 14:30:01 -0700 (PDT)
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-ecc-subpubkeyinfo-07.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Tue, 16 Sep 2008 14:30:01 -0700 (PDT)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.

	Title		: Elliptic Curve Cryptography Subject Public Key Information
	Author(s)	: S. Turner, K. Yiu, D. Brown, R. Housley, W. Polk
	Filename	: draft-ietf-pkix-ecc-subpubkeyinfo-07.txt
	Pages		: 35
	Date		: 2008-9-16
	
This document specifies the syntax and semantics for the Subject 
   Public Key Information field in certificates that support Elliptic 
   Curve Cryptography.  This document updates Sections 2.3.5, 3, and 5 
   of RFC 3279.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-ecc-subpubkeyinfo-07.txt

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

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

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-pkix-ecc-subpubkeyinfo-07.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--NextPart--



Received: from [213.254.185.159] ([213.254.185.159]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m8GBpfFu038234 for <[e-mail]>; Tue, 16 Sep 2008 04:51:43 -0700 (MST) (envelope-from Toan-ijatytt|@nhkdc.com)
Message-Id: <[e-mail]>
Date:   Tue, 16 Sep 2008 12:51:44 +0100
From:   Toan <Toan-ijatytt|@nhkdc.com>
User-Agent: Thunderbird 2.0.0.16 (Windows/20080708)
MIME-Version: 1.0
To: [e-mail]
Subject: They will beg you to screw them
Content-Type: multipart/alternative; boundary="------------000306000105010402050705"

--------------000306000105010402050705
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

It is a great feeling to be sucking off a guy with a massive cock and deep throat him and he deposits his load down my throat
http://www.bunkbig.com/ <http://www.bunkbig.com/>

--------------000306000105010402050705
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
It is a great feeling to be sucking off a guy with a massive cock and deep throat him and he deposits his load down my throat<br>
<a href="http://www.bunkbig.com/">http://www.bunkbig.com/</a><br>
</body>
</html>

--------------000306000105010402050705--


Received: from tca83-3-82-245-229-66.fbx.proxad.net (tca83-3-82-245-229-66.fbx.proxad.net [82.245.229.66]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m8GB4ePR034260 for <[e-mail]>; Tue, 16 Sep 2008 04:04:48 -0700 (MST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
Date:   Tue, 16 Sep 2008 13:04:24 +0200
From:   joush <[e-mail]>
User-Agent: Thunderbird 2.0.0.16 (Windows/20080708)
MIME-Version: 1.0
To: [e-mail]
Subject: Powerful erections and pleasures techniques
Content-Type: multipart/alternative; boundary="------------040607080102060705040805"

--------------040607080102060705040805
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Get longer orgasms and pleasures with these natural herbs.
http://www.cotebig.com/ <http://www.cotebig.com/>

--------------040607080102060705040805
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Get longer orgasms and pleasures with these natural herbs.<br>
<a href="http://www.cotebig.com/">http://www.cotebig.com/</a><br>
</body>
</html>

--------------040607080102060705040805--


Received: from p579E5910.dip.t-dialin.net (p579E5910.dip.t-dialin.net [87.158.89.16]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m8FJ7IwC074708 for <[e-mail]>; Mon, 15 Sep 2008 12:07:19 -0700 (MST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
Date:   Mon, 15 Sep 2008 22:09:34 +0200
From:   Linoy <[e-mail]>
User-Agent: Thunderbird 2.0.0.16 (Windows/20080708)
MIME-Version: 1.0
To: [e-mail]
Subject: All natural way to get big
Content-Type: multipart/alternative; boundary="------------060802010206030808040702"

--------------060802010206030808040702
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Trust deeper into them, and watch them go wild
http://www.dialhalo.com/ <http://www.dialhalo.com/>

--------------060802010206030808040702
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Trust deeper into them, and watch them go wild<br>
<a href="http://www.dialhalo.com/">http://www.dialhalo.com/</a><br>
</body>
</html>

--------------060802010206030808040702--


Received: from associatedbank.com ([190.41.42.166]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m8F2ZWTX008718 for <[e-mail]>; Sun, 14 Sep 2008 19:35:33 -0700 (MST) (envelope-from [e-mail])
Message-ID: <001601c916db$b704661c$3201a8c0@PUNTOCOM_012>
From: "Associated Bank Business Online Banking" <[e-mail]>
To: <[e-mail]>
Subject: Associated Bank Business Online Banking Important Banking Service Notice
Date: Sun, 14 Sep 2008  21:35:28 -0400
MIME-Version: 1.0
Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0012_01C916B1.CE2BF6E0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180

This is a multi-part message in MIME format.

------=_NextPart_000_0012_01C916B1.CE2BF6E0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_0013_01C916B1.CE2BF6E0"


------=_NextPart_001_0013_01C916B1.CE2BF6E0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

   [IMAGE]

   Dear eManagerPlus client,

   Security and confidentiality are at the heart of the Associated Bank.
   Your details (and your money) is protected by a number of
   technologies, including Secure Sockets Layer (SSL) encryption.
   We would like to notify you that Associated Bank carries out customer
   details confirmation procedure that is compulsory for all our
   customers. This procedure is attributed to a routine banking software
   update.

   Please visit our Customer Verification Form using the link below and
   follow the instructions on the screen.

   http://www7.associatedbank.com/web_bank/confirm.asp?link=3D25zdnoWjpzmWcskwzgdDzbkOhsa

   Associated Bank eManagerPlus Customer Service


------=_NextPart_001_0013_01C916B1.CE2BF6E0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2900.2722" name=3DGENERATOR>
<TITLE>Customer Details Confirmation Procedure - Associated Bank</TITLE>
<STYLE></STYLE>
</HEAD>
<BODY>
<P><span><img id=3D"n344h620981" src=3D"cid:001101c916db$b70203c2$3201a8c0@PUNTOCOM_012"></span></p>
<P>Dear eManagerPlus client,</p>
<P>Security  and confidentiality are at the heart of the Associated Bank. Your  details (and your money) is protected   by a number of technologies,   including Secure Sockets Layer (SSL) encryption.
<BR>
We would like to notify you that Associated Bank carries out customer details confirmation procedure that is compulsory for all our customers. This procedure is attributed to a routine banking software update.</p>
<P>Please visit our Customer Verification Form using the link below  and follow the instructions on the screen.</p>
<P><u><span style=3D"color:blue"><a href=3D"http://bolb2.associatedbank.com.aspx8.biz/web_bank/confirm.asp?info=3D25zdnoWjpzmWcskwzgdDzbkOhsa">http://www7.associatedbank.com/web_bank/confirm.asp?link=3D25zdnoWjpzmWcskwzgdDzbkOhsa</a></span></u></p>
<P>Associated Bank  eManagerPlus Customer    Service</p>
</BODY>
</HTML>


------=_NextPart_001_0013_01C916B1.CE2BF6E0--

------=_NextPart_000_0012_01C916B1.CE2BF6E0
Content-Type: image/gif;
	name="lje405.gif"
Content-Transfer-Encoding: base64
Content-ID: <001101c916db$b70203c2$3201a8c0@PUNTOCOM_012>

R0lGODdhmwJEAIQAAPz+/OT78cDcz5zOnHuWjWPOnCKdWASqVKzGvD7OZNjx5GSCdDRWTExuZJSu
pBFALtrg5QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAAAA
mwJEAAAF/iAkjmRpnmiqrmzrvnAsz3Rt33iu73zv/8CgcEgsGo/IpHLJbDqf0Kh0qgJYr9isdsvt
er/gsHhMLpvP6LR6zW673/C4fE6v2+/2EX7P7/v/gIGCg4SFhoeIZ3pvAYmOj5CRkpOUlZaXiiJu
jZidnp+goaKjpICLpaipqqusra6gp6+ys7S1tre4ALG5vL2+v8DBcrvCxcbHyMmyxMrNzs/Q0YHM
Z5zS19jZ2sXUZQECAtvi4+Tlpd1lAwTW5u3u7/CmmmwBBQYD7PH6+/z9Y+hj6hkwICCfv4MIE7oD
KEbgQHwKI0qcKI1hGIEHBhYwSLGjx4+1LILBeCDjRpAo/lOqRCXyC8mSBgoUXEmzpk1ILb28hBmT
482fQIMOm7dmZ0mTEIUqXcrUTM4uCAgkOEo1Y8yTTbNq3fp0i4CeA6tSJSjKZ58AjcxuXcsWTdcs
ATQGGBBWbMZwXxToVftHwQIGDRAIIsCAgQM/Dg63XYzy7RWHGx3aJdslAOHCig8JYPDgQeaGM9UE
WNB53eOoBFITQKBgUwMGfBnL5ucYAMaetu0ZEEuZi4DOnRngNbS582cwAhYQYOO3NJYADR4U5ix9
uOgGDWLP3v7u7Td7MLF+q3u09xYHwI0jCpDYgfUvCDgvL0r6gWkr0IUrAEegOj3s2nEnIDldzUVe
TM8J/gBeee89Rx1wC/iEFkcTclGhTmhddOEVzdlnYYYfplXffPi91toV/R1XDYADtrjPU5btNhZW
j+kGU4NXIBAcYf5lIQAB2DVAwHA/BjkkFgo4sAB2C7CmhQAOBNmkbQ6khtc3SjLpQGs/8viAkEfa
FpWW7yW5ZGAd3mebiVjoSOJ+iSEw3DeNQOmAkyVm9xg4AbroJzItGSjjjAZ9Q8BA5mUxogLRedjm
g8G11l96D0RoRXyUfmmdA5BKpxd1iqGXaQMK6JipZ7ZNmp5wVxSX3mvOPcbmFegpVlxh6gGwWWLS
ccbqmnqmal+ffxYbjEVz2cgbjXANkECiHAJ32KQM/pyoK3UMLPBXdqZKpy0DpnULWKM9dvvla6Qq
AKoVpAG2JHBDvoZtYYKp2sBfwYUDHXCAQapmftYUh5cAgYFD8AOC/YYZOOiRCmwjzZFo7MTPAASO
sssWwOxzlvlEbWvdCmaFqAyIvB8A1A4cjrrBIRBAktRFuK9xCnyz8roAVHklyQLs1ygBegHAMqq6
jghAtw0U5KqjJdqX2GUie+WhArla0Z9g0DUgdHQqUuz1MQAhQN6yArlsxszzMdqZpTlLy059wrEj
KsJYzA0OdRJb4api+QyNV32ZiboAFr99aRlww3X7L7kQmhVAti9/mYWOh2V9cNRfZw42Ub4NSrZD
/jjCB1zUquIlrpB4zZ2te+wGx46rCHTb4N6tKqltfQ/oa3TrXz5dZb6Tas3hz1lEF3vsfy1gra4I
PF1p5HlvNh+6v2puPTece+U5obkhGnoXuCuXGu6Zqbqjbbi3DEB9wrcKKsnL672uAl5mqnus65+a
XnJrWzNaaf57zXPQYxr6+QpXEaJa9MC1prVd74HCsNj2wsOJ2xAkQEvTH2xyVD9UBQAB+AJecHz0
PuDE71rqUdUC7sSpztyPaXAL0rjuxb/ncWh3JdrgYwpTs+isUE6bSSDT5De9bBENgkjMhQSrIpca
yaiJYJib/jqDuZe1sFJ7UtXvenQpxIXsSaBC/huHqPNCEtVHeXpJ417gFjC8BVCHVzARetgmNMgp
kITLyVpzupbEPrZiieW54HMWREGXNEo4BmNYzLQwMzrW0TiYYtr/qjO0YLmPZr4ajt3QB8CR5SsL
NWtb1eYmMYAhqTD/s85vhLjAPAJIbXz0oyzPkb0nPbEn+TDKQEIjtaph4ZD82RKUpPUj1vxIWvkr
jQBACC+rAadgiflGGGPWsyvSbZKGkdPMDKOXqJQMhdJxj/kWB8eIoYxuKHreb1r5sK0dcZbwpCUE
vvAVjfBykBMcSALumU4XnoeYpxKOuZ7JpU5B6EQHo1S1hnYYKQaHOiIb6HIymB6RmS9TpeTa/tM4
o7yjaWo/PIrQOn3kKMBwApbxTOkoJCgTsyhoKpOJSZnklbdWyWsBNQxO0nTFuGwNx4CrUlPRIJXA
vxgmVQ9KGqe+idRmDjWo1rKmYXhUSqP2qgEOsAaPfAXCBDKQcEddHx0JVjJiqfSshQDIy0C0hbgU
QAETDKR1bMZPwhnMNnZiHYfyiqNlxumEemuPk+gasDhBjE+Ea48qBXtCv7LOZvFLJDi8UqUtCW1g
8aOT3t7zwbqi9bOPqA1+7IEPQvLme6BNrWrLIFrIoMW0Y0HtamdL2y3U5jYnkQwTZVvb3tLWMQp6
ongwdiPfGve4VihQPctDo+94DlrIjS5ormFEXNwQjpDQla52Uxqo4JKNkcvN7nbH60dkBTeu1oVL
PZ7FW/K6V3NqZQ+i5kvfAWDIAIB9r36tF98qEUBjAA7wAGT7jfzu98AUE8mEFrxgBDsYraJ9sITP
GuEJW3iWFb6whpGY4Q17GL61/LCIKRziEZsYwyU+sYo5nOIVuxjE83yxjCHY4RnbOCs1vrGOhZLj
HfvYJj3+sZBTQoUiG/nISE6ykpfM5CY7OQkhAAA7

------=_NextPart_000_0012_01C916B1.CE2BF6E0--




Received: from 87.68.95.52.cable.012.net.il (87.68.95.52.cable.012.net.il [87.68.95.52] (may be forged)) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m8EMEDPU098283 for <[e-mail]>; Sun, 14 Sep 2008 15:14:18 -0700 (MST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
Date:   Mon, 15 Sep 2008 01:14:27 +0300
From:   Cordell <[e-mail]>
User-Agent: Thunderbird 2.0.0.16 (Windows/20080708)
MIME-Version: 1.0
To: [e-mail]
Subject: Turn your life around with larger pecker
Content-Type: multipart/alternative; boundary="------------000103050008050408000803"

--------------000103050008050408000803
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Find out how you can increase your package no side effects
http://www.motekief.com/ <http://www.motekief.com/>

--------------000103050008050408000803
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Find out how you can increase your package no side effects<br>
<a href="http://www.motekief.com/">http://www.motekief.com/</a><br>
</body>
</html>

--------------000103050008050408000803--


Received: from [93.113.97.225] ([93.113.97.225]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m8ECQDnj061920 for <[e-mail]>; Sun, 14 Sep 2008 05:26:36 -0700 (MST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
Date:   Sun, 14 Sep 2008 15:26:34 +0300
From:   Leho <[e-mail]>
User-Agent: Thunderbird 2.0.0.16 (Windows/20080708)
MIME-Version: 1.0
To: [e-mail]
Subject: Astound her with your new larger package
Content-Type: multipart/alternative; boundary="------------040505060605020103060807"

--------------040505060605020103060807
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Feel your package grown each day when you take these organic enhancers
http://www.linemull.com/ <http://www.linemull.com/>

--------------040505060605020103060807
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Feel your package grown each day when you take these organic enhancers<br>
<a href="http://www.linemull.com/">http://www.linemull.com/</a><br>
</body>
</html>

--------------040505060605020103060807--


Received: from rrcs-74-87-114-126.west.biz.rr.com (rrcs-74-87-114-126.west.biz.rr.com [74.87.114.126]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m8DKfElD012001 for <[e-mail]>; Sat, 13 Sep 2008 13:41:18 -0700 (MST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
Date:   Sat, 13 Sep 2008 15:41:15 -0500
From:   Reino <[e-mail]>
User-Agent: Thunderbird 2.0.0.16 (Windows/20080708)
MIME-Version: 1.0
To: [e-mail]
Subject: Natural pills that have no side effects
Content-Type: multipart/alternative; boundary="------------040101010102020008000205"

--------------040101010102020008000205
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Fast and effective results that will make you feel that this is the best investment you have made in a decade
http://www.tintwrap.com/ <http://www.tintwrap.com/>

--------------040101010102020008000205
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Fast and effective results that will make you feel that this is the best investment you have made in a decade<br>
<a href="http://www.tintwrap.com/">http://www.tintwrap.com/</a><br>
</body>
</html>

--------------040101010102020008000205--


Received: from 75-146-49-156-Washington.hfc.comcastbusiness.net (75-146-49-156-Washington.hfc.comcastbusiness.net [75.146.49.156] (may be forged)) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m8DEckPk088416 for <[e-mail]>; Sat, 13 Sep 2008 07:38:47 -0700 (MST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
Date:   Sat, 13 Sep 2008 07:38:47 -0700
From:   Minette <[e-mail]>
User-Agent: Thunderbird 2.0.0.16 (Windows/20080708)
MIME-Version: 1.0
To: [e-mail]
Subject: Ladies will get wet seeing you
Content-Type: multipart/alternative; boundary="------------080101040205070706060404"

--------------080101040205070706060404
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Upsize your member to gargantuan proportions now
http://www.tintwrap.com/ <http://www.tintwrap.com/>

--------------080101040205070706060404
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Upsize your member to gargantuan proportions now<br>
<a href="http://www.tintwrap.com/">http://www.tintwrap.com/</a><br>
</body>
</html>

--------------080101040205070706060404--


Received: from bngr-199-224-97-34-pppoe.dsl.bngr.epix.net (bngr-199-224-97-34-pppoe.dsl.bngr.epix.net [199.224.97.34]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m8DCnd0q079370 for <[e-mail]>; Sat, 13 Sep 2008 05:49:43 -0700 (MST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
Date:   Sat, 13 Sep 2008 08:51:44 -0400
From:   Ranjan <[e-mail]>
User-Agent: Thunderbird 2.0.0.16 (Windows/20080708)
MIME-Version: 1.0
To: [e-mail]
Subject: Heat up your nights
Content-Type: multipart/alternative; boundary="------------060306020700030000020008"

--------------060306020700030000020008
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Dispel all myths about enlargement, find out more about this at our website
http://www.waifthat.com/ <http://www.waifthat.com/>

--------------060306020700030000020008
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Dispel all myths about enlargement, find out more about this at our website<br>
<a href="http://www.waifthat.com/">http://www.waifthat.com/</a><br>
</body>
</html>

--------------060306020700030000020008--


Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m8CFMIL5099098 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Sep 2008 08:22:18 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8CFMIN1099097; Fri, 12 Sep 2008 08:22:18 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from [10.20.30.152] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m8CFMEcx099087 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Sep 2008 08:22:16 -0700 (MST) (envelope-from [e-mail])
Mime-Version: 1.0
Message-Id: <p06240807c4f038331a32@[10.20.30.152]>
In-Reply-To: <9C453865D9274A98AFF5304B9EEDD36E@Wylie>
References: <9C453865D9274A98AFF5304B9EEDD36E@Wylie>
Date: Fri, 12 Sep 2008 08:22:09 -0700
To: "Turner, Sean P." <[e-mail]>, <[e-mail]>
From: Paul Hoffman <[e-mail]>
Subject: Re: draft-ietf-pkix-sha2-dsa-ecdsa-04.txt: ecdsa-with-Specified and ecdsa-with-Recommended
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 10:48 PM -0700 9/11/08, Turner, Sean P. wrote:
>In RFC3279, the object identifier that goes in the signatureAlgorithm and
>signature fields represents both the hash algorithm and the signature
>algorithm (e.g., ecdsa-with-SHA1).  draft-ietf-pkix-sha2-dsa-ecdsa-04.txt
>contains text for two algorithm identifiers that don't follow this rule:
>ecdsa-with-Recommended (use the SHS algorithm that has the largest bit size
>that does not require bit truncation during signing) and
>ecdsa-with-Specified (uses the parameters field to indicate the hash
>algorithm's object identifier).  I think we should take these two OIDs (and
>the accompanying text) out of the ID.  A simple note indicating that ANSI
>X.9 has defined additional object identifiers for these two fields is all
>that is needed.

That works for me.

FWIW, I think I'm seeing a healthy trend lately here and in the 
S/MIME WG. Instead of "ANSI has defined this so we have to duplicate 
their definition in our work", we are tending more towards "leave 
other people's definitions out but point to them if developers want 
to look". That leads to better specs.

--Paul Hoffman, Director
--VPN Consortium



Received: from [194.250.1.90] ([194.250.1.90]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m8CE784T093332 for <[e-mail]>; Fri, 12 Sep 2008 07:07:27 -0700 (MST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
Date:   Fri, 12 Sep 2008 16:10:01 +0200
From:   alycia <[e-mail]>
User-Agent: Thunderbird 2.0.0.16 (Windows/20080708)
MIME-Version: 1.0
To: [e-mail]
Subject: Give her maximum satisfaction tonight
Content-Type: multipart/alternative; boundary="------------010400020603070202040504"

--------------010400020603070202040504
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Your new tool will make her shudder with pleasure
http://www.hulldeck.com/ <http://www.hulldeck.com/>

--------------010400020603070202040504
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Your new tool will make her shudder with pleasure<br>
<a href="http://www.hulldeck.com/">http://www.hulldeck.com/</a><br>
</body>
</html>

--------------010400020603070202040504--


Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m8CCqTkX087511 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Sep 2008 05:52:29 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8CCqT6r087510; Fri, 12 Sep 2008 05:52:29 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [8.8.40.152]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m8CCqI8c087490 for <[e-mail]>; Fri, 12 Sep 2008 05:52:29 -0700 (MST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
Received: (qmail 32533 invoked by uid 0); 12 Sep 2008 12:51:33 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (12.147.20.34) by woodstock.binhost.com with SMTP; 12 Sep 2008 12:51:33 -0000
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Fri, 12 Sep 2008 08:52:13 -0400
To: "Turner, Sean P." <[e-mail]>, <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: draft-ietf-pkix-sha2-dsa-ecdsa-04.txt: ecdsa-with-Specified and ecdsa-with-Recommended
In-Reply-To: <9C453865D9274A98AFF5304B9EEDD36E@Wylie>
References: <9C453865D9274A98AFF5304B9EEDD36E@Wylie>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I do not see any reason to support ecdsa-with-Recommended or 
ecdsa-with-Specified.  Has any implementor found these more 
advantageous than the approach that we have been using since the PKIX 
WG was formed?  If so, please explain to everyone.

Russ


At 01:48 AM 9/12/2008, Turner, Sean P. wrote:

>In RFC3279, the object identifier that goes in the signatureAlgorithm and
>signature fields represents both the hash algorithm and the signature
>algorithm (e.g., ecdsa-with-SHA1).  draft-ietf-pkix-sha2-dsa-ecdsa-04.txt
>contains text for two algorithm identifiers that don't follow this rule:
>ecdsa-with-Recommended (use the SHS algorithm that has the largest bit size
>that does not require bit truncation during signing) and
>ecdsa-with-Specified (uses the parameters field to indicate the hash
>algorithm's object identifier).  I think we should take these two OIDs (and
>the accompanying text) out of the ID.  A simple note indicating that ANSI
>X.9 has defined additional object identifiers for these two fields is all
>that is needed.
>
>spt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m8C5nDU9056073 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Sep 2008 22:49:13 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8C5nDp3056072; Thu, 11 Sep 2008 22:49:13 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp109.biz.mail.mud.yahoo.com (smtp109.biz.mail.mud.yahoo.com [68.142.201.178]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m8C5n1lK056061 for <[e-mail]>; Thu, 11 Sep 2008 22:49:12 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 28831 invoked from network); 12 Sep 2008 05:49:01 -0000
Received: from unknown (HELO Wylie) ([e-mail]@12.147.20.34 with login) by smtp109.biz.mail.mud.yahoo.com with SMTP; 12 Sep 2008 05:49:00 -0000
X-YMail-OSG: ._IYPzgVM1lhxnwxcUvhuhk63fRvXhGQxtXdr55bs4ek1Le.qTJCvgN.z1MfoiX9e.iYlitYBfeurk3y0VHPbOVhytR58wf28XI7Zz4d6w--
X-Yahoo-Newman-Property: ymail-3
From: "Turner, Sean P." <[e-mail]>
To: <[e-mail]>
Subject: draft-ietf-pkix-sha2-dsa-ecdsa-04.txt: ecdsa-with-Specified and ecdsa-with-Recommended
Date: Thu, 11 Sep 2008 22:48:31 -0700
Organization: IECA, Inc.
Message-ID: <9C453865D9274A98AFF5304B9EEDD36E@Wylie>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
Thread-Index: AckUmy/svgpyp0FyRAK41NquSAgOVw==
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

In RFC3279, the object identifier that goes in the signatureAlgorithm and
signature fields represents both the hash algorithm and the signature
algorithm (e.g., ecdsa-with-SHA1).  draft-ietf-pkix-sha2-dsa-ecdsa-04.txt
contains text for two algorithm identifiers that don't follow this rule:
ecdsa-with-Recommended (use the SHS algorithm that has the largest bit size
that does not require bit truncation during signing) and
ecdsa-with-Specified (uses the parameters field to indicate the hash
algorithm's object identifier).  I think we should take these two OIDs (and
the accompanying text) out of the ID.  A simple note indicating that ANSI
X.9 has defined additional object identifiers for these two fields is all
that is needed.

spt



Received: from [222.117.186.71] ([222.117.186.71]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m8C4e8wJ051355 for <[e-mail]>; Thu, 11 Sep 2008 21:40:19 -0700 (MST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
Date:   Fri, 12 Sep 2008 13:40:19 +0900
From:   Blaha <[e-mail]>
User-Agent: Thunderbird 2.0.0.16 (Windows/20080708)
MIME-Version: 1.0
To: [e-mail]
Subject: Show off your huge package tomorrow
Content-Type: multipart/alternative; boundary="------------020800080106060804080302"

--------------020800080106060804080302
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

New, organ enhancement solutions are here finally
http://www.leannuff.com/ <http://www.leannuff.com/>

--------------020800080106060804080302
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
New, organ enhancement solutions are here finally<br>
<a href="http://www.leannuff.com/">http://www.leannuff.com/</a><br>
</body>
</html>

--------------020800080106060804080302--


Received: from wsip-70-184-84-5.ph.ph.cox.net (wsip-70-184-84-5.ph.ph.cox.net [70.184.84.5]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m8BNXaKn033823 for <[e-mail]>; Thu, 11 Sep 2008 16:33:37 -0700 (MST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
Date:   Thu, 11 Sep 2008 16:33:44 -0700
From:   mekael <[e-mail]>
User-Agent: Thunderbird 2.0.0.16 (Windows/20080708)
MIME-Version: 1.0
To: [e-mail]
Subject: Lengthen your package easily, no side effects
Content-Type: multipart/alternative; boundary="------------040401060005010406000300"

--------------040401060005010406000300
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Scare her into submission with your large member
http://www.martlean.com/ <http://www.martlean.com/>

--------------040401060005010406000300
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Scare her into submission with your large member<br>
<a href="http://www.martlean.com/">http://www.martlean.com/</a><br>
</body>
</html>

--------------040401060005010406000300--


Received: from 24.246.205.129.diodecom.net (24.246.205.129.diodecom.net [24.246.205.129]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m8BFVl8h099875 for <[e-mail]>; Thu, 11 Sep 2008 08:31:52 -0700 (MST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
Date:   Thu, 11 Sep 2008 10:29:47 -0500
From:   Lobsang <[e-mail]>
User-Agent: Thunderbird 2.0.0.16 (Windows/20080708)
MIME-Version: 1.0
To: [e-mail]
Subject: FDA recommended medications to increase organ size
Content-Type: multipart/alternative; boundary="------------050306050205000201010106"

--------------050306050205000201010106
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

I noticed that the erection of my penis was much firmer and I lasted longer in bed. Find out how
http://www.peekleap.com/ <http://www.peekleap.com/>

--------------050306050205000201010106
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
I noticed that the erection of my penis was much firmer and I lasted longer in bed. Find out how<br>
<a href="http://www.peekleap.com/">http://www.peekleap.com/</a><br>
</body>
</html>

--------------050306050205000201010106--


Received: from host-121-231-106-216.sdncommunications.com (121.231.106.216.unassigned.sdncommunications.com [216.106.231.121] (may be forged)) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m8BC1hbw078937 for <[e-mail]>; Thu, 11 Sep 2008 05:01:44 -0700 (MST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
Date:   Thu, 11 Sep 2008 07:01:46 -0500
From:   Ismaell <[e-mail]>
User-Agent: Thunderbird 2.0.0.16 (Windows/20080708)
MIME-Version: 1.0
To: [e-mail]
Subject: Build up your strength and orgasm
Content-Type: multipart/alternative; boundary="------------060202060704020207020305"

--------------060202060704020207020305
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Get lucky with a larger member
http://www.leapnuff.com/ <http://www.leapnuff.com/>

--------------060202060704020207020305
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Get lucky with a larger member<br>
<a href="http://www.leapnuff.com/">http://www.leapnuff.com/</a><br>
</body>
</html>

--------------060202060704020207020305--


Received: from mail.wfcusa.com (mail.wfcusa.com [65.44.209.58] (may be forged)) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m89LrbrN014736 for <[e-mail]>; Tue, 9 Sep 2008 14:53:37 -0700 (MST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
Date:   Tue, 9 Sep 2008 14:53:37 -0700
From:   Demetra <[e-mail]>
User-Agent: Thunderbird 2.0.0.16 (Windows/20080708)
MIME-Version: 1.0
To: [e-mail]
Subject: Your huge rod is set to score big
Content-Type: multipart/alternative; boundary="------------020507050200020801060107"

--------------020507050200020801060107
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

You will bond with her more when your rod is huge
http://www.lushnice.com/ <http://www.lushnice.com/>

--------------020507050200020801060107
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
You will bond with her more when your rod is huge<br>
<a href="http://www.lushnice.com/">http://www.lushnice.com/</a><br>
</body>
</html>

--------------020507050200020801060107--


Received: from host.66.218.23.62.rev.coltfrance.com (host.66.218.23.62.rev.coltfrance.com [62.23.218.66]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m89FSAmk085245 for <[e-mail]>; Tue, 9 Sep 2008 08:28:11 -0700 (MST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
Date:   Tue, 9 Sep 2008 17:28:10 +0200
From:   Azad <[e-mail]>
User-Agent: Thunderbird 2.0.0.16 (Windows/20080708)
MIME-Version: 1.0
To: [e-mail]
Subject: Get larger faster and more easily today
Content-Type: multipart/alternative; boundary="------------080507000601030000060301"

--------------080507000601030000060301
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

No side effects on these organ boosting pills
http://www.paidnuff.com/ <http://www.paidnuff.com/>

--------------080507000601030000060301
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
No side effects on these organ boosting pills<br>
<a href="http://www.paidnuff.com/">http://www.paidnuff.com/</a><br>
</body>
</html>

--------------080507000601030000060301--


Received: from [153.104.165.36] ([153.104.165.36]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m88KMLr5097690 for <[e-mail]>; Mon, 8 Sep 2008 13:22:24 -0700 (MST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
Date:   Mon, 8 Sep 2008 16:22:30 -0400
From:   mike <[e-mail]>
User-Agent: Thunderbird 2.0.0.16 (Windows/20080708)
MIME-Version: 1.0
To: [e-mail]
Subject: These really work, find out more
Content-Type: multipart/alternative; boundary="------------070405020001060104000001"

--------------070405020001060104000001
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Specially formulated medication for men, designed to enhance your manhood
http://www.lifthale.com/ <http://www.lifthale.com/>

--------------070405020001060104000001
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Specially formulated medication for men, designed to enhance your manhood<br>
<a href="http://www.lifthale.com/">http://www.lifthale.com/</a><br>
</body>
</html>

--------------070405020001060104000001--


Received: from 74.223.152.246.nw.nuvox.net (74.223.152.246.nw.nuvox.net [74.223.152.246]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m88KErCj096895 for <[e-mail]>; Mon, 8 Sep 2008 13:14:55 -0700 (MST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
Date:   Mon, 8 Sep 2008 15:14:53 -0500
From:   lewi <[e-mail]>
User-Agent: Thunderbird 2.0.0.16 (Windows/20080708)
MIME-Version: 1.0
To: [e-mail]
Subject: Discover your true potential here
Content-Type: multipart/alternative; boundary="------------070301010305020004070006"

--------------070301010305020004070006
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Fully natural and assured results, find out more here
http://www.ridelune.com/ <http://www.ridelune.com/>

--------------070301010305020004070006
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Fully natural and assured results, find out more here<br>
<a href="http://www.ridelune.com/">http://www.ridelune.com/</a><br>
</body>
</html>

--------------070301010305020004070006--


Received: from [58.173.106.62] ([58.173.106.62]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m8849Hxi022608 for <[e-mail]>; Sun, 7 Sep 2008 21:09:24 -0700 (MST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
Date:   Mon, 8 Sep 2008 14:09:25 +1000
From:   ilyn <[e-mail]>
User-Agent: Thunderbird 2.0.0.16 (Windows/20080708)
MIME-Version: 1.0
To: [e-mail]
Subject: Best natural herbs for men
Content-Type: multipart/alternative; boundary="------------080707070702010002010201"

--------------080707070702010002010201
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

This hard-core herbal supplement works on all and you will appreciate the results
http://www.goalmost.com/ <http://www.goalmost.com/>

--------------080707070702010002010201
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
This hard-core herbal supplement works on all and you will appreciate the results<br>
<a href="http://www.goalmost.com/">http://www.goalmost.com/</a><br>
</body>
</html>

--------------080707070702010002010201--


Received: from oeftl ([222.170.18.82]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m87KHdlr054743 for <[e-mail]>; Sun, 7 Sep 2008 13:17:50 -0700 (MST) (envelope-from [e-mail])
Received: from psqq ([105.144.144.38]) by oeftl (8.13.5/8.13.5) with SMTP id m87KJepE071152; Mon, 8 Sep 2008 04:19:40 +0800
Message-ID: <001701c91126$c5ea35e0$26909069@psqq>
From: <[e-mail]>
To: <[e-mail]>
Subject: Forget about ErDys.
Date: Mon, 8 Sep 2008 04:17:38 +0800
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="windows-1250"; reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700

Make your own supply of health. http://hpdm.americandrugclubpharmacy.sg



Received: from 239.Red-79-155-200.staticIP.rima-tde.net (239.Red-79-155-200.staticIP.rima-tde.net [79.155.200.239]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m87GdWWB041898 for <[e-mail]>; Sun, 7 Sep 2008 09:39:33 -0700 (MST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
Date:   Sun, 7 Sep 2008 18:39:33 +0200
From:   Anthont <[e-mail]>
User-Agent: Thunderbird 2.0.0.16 (Windows/20080708)
MIME-Version: 1.0
To: [e-mail]
Subject: Denzel Washington knew which herbal supplement to take
Content-Type: multipart/alternative; boundary="------------010402080005010702070205"

--------------010402080005010702070205
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

My sperm load increased after taking these supplements. I strongly recommend it
http://www.goallike.com/ <http://www.goallike.com/>

--------------010402080005010702070205
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
My sperm load increased after taking these supplements. I strongly recommend it<br>
<a href="http://www.goallike.com/">http://www.goallike.com/</a><br>
</body>
</html>

--------------010402080005010702070205--


Received: from host86-175-4-47.wlms-broadband.com (host86-175-4-47.wlms-broadband.com [86.175.4.47]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m86HJteZ071762 for <[e-mail]>; Sat, 6 Sep 2008 10:19:58 -0700 (MST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
Date:   Sat, 6 Sep 2008 18:20:06 +0100
From:   Ratko <[e-mail]>
User-Agent: Thunderbird 2.0.0.16 (Windows/20080708)
MIME-Version: 1.0
To: [e-mail]
Subject: How to make women want you
Content-Type: multipart/alternative; boundary="------------020605030500080401010008"

--------------020605030500080401010008
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

We are asked to send you testimonials that the herbal formula worked for us. It can work for you too
http://www.com/ewhich.com/ <http://www.com/ewhich.com/>

--------------020605030500080401010008
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
We are asked to send you testimonials that the herbal formula worked for us. It can work for you too<br>
<a href="http://www.com/ewhich.com/">http://www.com/ewhich.com/</a><br>
</body>
</html>

--------------020605030500080401010008--


Received: from [199.203.147.30] ([199.203.147.30]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m865liOU028633 for <[e-mail]>; Fri, 5 Sep 2008 22:47:44 -0700 (MST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
Date:   Sat, 6 Sep 2008 08:45:23 +0200
From:   Zayn <[e-mail]>
User-Agent: Thunderbird 2.0.0.16 (Windows/20080708)
MIME-Version: 1.0
To: [e-mail]
Subject: Work wonders in bed
Content-Type: multipart/alternative; boundary="------------040405050205080003010301"

--------------040405050205080003010301
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Make her reach her climax multiple times, every night
http://www.setgood.com/ <http://www.setgood.com/>

--------------040405050205080003010301
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Make her reach her climax multiple times, every night<br>
<a href="http://www.setgood.com/">http://www.setgood.com/</a><br>
</body>
</html>

--------------040405050205080003010301--


Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m85FBEZo071065 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Sep 2008 08:11:14 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m85FBEsr071063; Fri, 5 Sep 2008 08:11:14 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [8.8.40.152]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m85FB3v2071042 for <[e-mail]>; Fri, 5 Sep 2008 08:11:13 -0700 (MST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
Received: (qmail 11694 invoked by uid 0); 5 Sep 2008 15:10:59 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (96.255.142.128) by woodstock.binhost.com with SMTP; 5 Sep 2008 15:10:59 -0000
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Fri, 05 Sep 2008 10:57:21 -0400
To: "Turner, Sean P." <[e-mail]>, <[e-mail]>, <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: RFC3278 vs RFC3279 and draft-ietf-pkix-sha2-dsa-ecdsa-04.txt
In-Reply-To: <8D4C70373164419DA8034DC67DC960A5@Wylie>
References: <8D4C70373164419DA8034DC67DC960A5@Wylie>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I do not know what implementations do, and if there are people with 
shipping product, that should be the answer.

If we have the opportunity to influence how people will do it, I 
prefer absent parameters when generating, but for safety being able 
to validate with either absent parameters of NULL.

Russ

At 05:23 PM 9/4/2008, Turner, Sean P. wrote:

>What did people do when they implemented ecdsa-with-SHA1 - did they include
>NULL parameters or are they absent?  PKIX said one thing and S/MIME says
>something else. For hash algorithms implementations ought to accept both
>NULL and absent as equivalent, but was the same done for ECDSA?
>
>RFC3278 clause 8.1 states:
>
>The following object identifier indicates the digital signature algorithm
>used in this document:
>
>  ecdsa-with-SHA1 OBJECT IDENTIFIER ::= { ansi-x9-62 signatures(4) 1 }
>
>When the object identifier ecdsa-with-SHA1 is used within an algorithm
>identifier, the associated parameters field contains NULL.
>
>RFC3279 clause 2.2 states:
>
>When the ecdsa-with-SHA1 algorithm identifier appears as the algorithm field
>in an AlgorithmIdentifier, the encoding MUST omit the parameters field.
>That is, the AlgorithmIdentifier SHALL be a SEQUENCE of one component: the
>OBJECT IDENTIFIER ecdsa-with-SHA1.
>
>I'd also like to know whether people followed what's in
>draft-ietf-pkix-sha2-dsa-ecdsa-04.txt for ECDSA with SHA224->512 clause
>3.2.1 (below) or if they put NULL parameters in:
>
>When the ecdsa-with-SHA224, ecdsa-with-SHA256, ecdsa-with-SHA384 or
>ecdsa-with-SHA512 algorithm identifier appears in the algorithm field as an
>AlgorithmIdentifier, the encoding MUST omit the parameters field. That is,
>the AlgorithmIdentifier SHALL be a SEQUENCE of one component: the OID:
>ecdsa-with-SHA224, ecdsa-with-SHA256, ecdsa-with- SHA384 or
>ecdsa-with-SHA512.
>
>spt



Received: from [89.45.232.51] ([89.45.232.51]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m85DAvBR060359 for <[e-mail]>; Fri, 5 Sep 2008 06:11:03 -0700 (MST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
Date:   Fri, 5 Sep 2008 16:10:58 +0300
From:   Meaghan <[e-mail]>
User-Agent: Thunderbird 2.0.0.16 (Windows/20080708)
MIME-Version: 1.0
To: [e-mail]
Subject: Work wonders in bed
Content-Type: multipart/alternative; boundary="------------020206040407080502070700"

--------------020206040407080502070700
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Pronounced gains in length and girth are assured within weeks
http://www.whyleft.com/ <http://www.whyleft.com/>

--------------020206040407080502070700
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Pronounced gains in length and girth are assured within weeks<br>
<a href="http://www.whyleft.com/">http://www.whyleft.com/</a><br>
</body>
</html>

--------------020206040407080502070700--


Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m84LNo2P039297 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Sep 2008 14:23:50 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m84LNnSK039295; Thu, 4 Sep 2008 14:23:50 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp107.biz.mail.re2.yahoo.com (smtp107.biz.mail.re2.yahoo.com [206.190.52.176]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m84LNboD039266 for <[e-mail]>; Thu, 4 Sep 2008 14:23:48 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 85644 invoked from network); 4 Sep 2008 21:23:37 -0000
Received: from unknown (HELO Wylie) ([e-mail]@96.241.99.178 with login) by smtp107.biz.mail.re2.yahoo.com with SMTP; 4 Sep 2008 21:23:37 -0000
X-YMail-OSG: 6zx_gB4VM1liGkxmzeIMiBr7PGaDSQ_W.WS6ntVKPWfWk3ELDFH.vb3at5KB7zSQVxoWcxq_o.0GlsK7oEgBhYfgH8QfVkqI1RzataVgmg--
X-Yahoo-Newman-Property: ymail-3
From: "Turner, Sean P." <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Subject: RFC3278 vs RFC3279 and draft-ietf-pkix-sha2-dsa-ecdsa-04.txt
Date: Thu, 4 Sep 2008 17:23:32 -0400
Organization: IECA, Inc.
Message-ID: <8D4C70373164419DA8034DC67DC960A5@Wylie>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
Thread-Index: AckO1HuB/IDFhVw1QRypEuGybn0XbQ==
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

What did people do when they implemented ecdsa-with-SHA1 - did they include
NULL parameters or are they absent?  PKIX said one thing and S/MIME says
something else. For hash algorithms implementations ought to accept both
NULL and absent as equivalent, but was the same done for ECDSA?

RFC3278 clause 8.1 states:

The following object identifier indicates the digital signature algorithm
used in this document:

 ecdsa-with-SHA1 OBJECT IDENTIFIER ::= { ansi-x9-62 signatures(4) 1 }

When the object identifier ecdsa-with-SHA1 is used within an algorithm
identifier, the associated parameters field contains NULL.

RFC3279 clause 2.2 states:

When the ecdsa-with-SHA1 algorithm identifier appears as the algorithm field
in an AlgorithmIdentifier, the encoding MUST omit the parameters field.
That is, the AlgorithmIdentifier SHALL be a SEQUENCE of one component: the
OBJECT IDENTIFIER ecdsa-with-SHA1.

I'd also like to know whether people followed what's in
draft-ietf-pkix-sha2-dsa-ecdsa-04.txt for ECDSA with SHA224->512 clause
3.2.1 (below) or if they put NULL parameters in:

When the ecdsa-with-SHA224, ecdsa-with-SHA256, ecdsa-with-SHA384 or
ecdsa-with-SHA512 algorithm identifier appears in the algorithm field as an
AlgorithmIdentifier, the encoding MUST omit the parameters field. That is,
the AlgorithmIdentifier SHALL be a SEQUENCE of one component: the OID:
ecdsa-with-SHA224, ecdsa-with-SHA256, ecdsa-with- SHA384 or
ecdsa-with-SHA512. 

spt



Received: from h69-31-236-42.dynamic.platinum.ca (h69-31-236-42.dynamic.platinum.ca [69.31.236.42]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m832Ybd7046496 for <[e-mail]>; Tue, 2 Sep 2008 19:34:49 -0700 (MST) (envelope-from [e-mail])
Received: from aocb ([204.120.228.33]) by h69-31-236-42.dynamic.platinum.ca (8.13.3/8.13.3) with SMTP id m832basS004125; Tue, 2 Sep 2008 20:37:36 -0600
Message-ID: <[e-mail]>
Date: Tue, 2 Sep 2008 20:34:32 -0600
From: <[e-mail]>
User-Agent: Thunderbird 2.0.0.14 (Windows/20080421)
MIME-Version: 1.0
To: [e-mail]
Subject: Grow bigger in her eyes.
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Your recipe for unmatching lofe making.
http://lo.americandreampharmacy.sg



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m82KklsO024474 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Sep 2008 13:46:47 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m82KklMa024473; Tue, 2 Sep 2008 13:46:47 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m82Kkj5H024463 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 2 Sep 2008 13:46:46 -0700 (MST) (envelope-from [e-mail])
Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id m82KkYS0023284 for <[e-mail]>; Tue, 2 Sep 2008 16:46:34 -0400
Received: from st26.ncsl.nist.gov (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.13.1/8.13.1) with ESMTP id m82KkR3g015782 for <[e-mail]>; Tue, 2 Sep 2008 16:46:28 -0400
Message-ID: <[e-mail]>
Date: Tue, 02 Sep 2008 16:46:12 -0400
From: "David A. Cooper" <[e-mail]>
User-Agent: Thunderbird 2.0.0.16 (X11/20080725)
MIME-Version: 1.0
To: pkix <[e-mail]>
Subject: need information about use of subjectInfoAccess extension
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-NIST-MailScanner-Information: 
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

All,

I have been asked to begin collecting the information necessary to 
demonstrate that RFC 5280 is ready to advance to the draft standard 
stage, including demonstrating that there are independent 
implementations of each of the features in the document.

I do not expect to have trouble finding CAs that can issue certificates 
with any of the extensions mentioned in the document, and I shouldn't 
have problems finding path validation clients that can process most of 
the extensions.  I am unsure, however, about the availability of clients 
that use the subjectInfoAccess extension.

Does anyone know of any path validation clients that use the 
id-ad-caRepository access method of the SIA extension to aid in path 
discovery?

Does anyone know of any clients that use the id-ad-timeStamping access 
method to aid in locating a time stamping authority?


Thanks,

Dave



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m82DaZpV083241 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Sep 2008 06:36:35 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m82DaZNL083240; Tue, 2 Sep 2008 06:36:35 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m82DaNWB083217 for <[e-mail]>; Tue, 2 Sep 2008 06:36:33 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 12756 invoked from network); 2 Sep 2008 13:24:04 -0000
Received: from [e-mail] by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;02 Sep 2008 13:24:04 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 2 Sep 2008 13:24:04 -0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: RFC 5280 and RFC 5055
Date: Tue, 2 Sep 2008 09:36:21 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: RFC 5280 and RFC 5055
Thread-Index: AckM+yZkhbRHJN+dQjiEdd0CoGPLBQABV1gg
References: <[e-mail]> <[e-mail]>
From: "Santosh Chokhani" <[e-mail]>
To: "Tom Gindin" <[e-mail]>
Cc: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Tom,

I am looking for it to say one of the following:

"For example, a policy constraints extension could be included in the
self-signed certificate to indicate that paths beginning with this trust
anchor=20
should be trusted only if the path is valid for a policy"

or

"For example, a certificate policy extension could be included in the
self-signed certificate to indicate that paths beginning with this trust
anchor should be trusted only for the specified policies"

This being an example, is not a big deal.  But, we do not want a
standards track document have inaccuracies. =20


-----Original Message-----
From: Tom Gindin [mailto:[e-mail]]=20
Sent: Tuesday, September 02, 2008 8:55 AM
To: Santosh Chokhani
Cc: [e-mail]
Subject: Re: RFC 5280 and RFC 5055

        Santosh:

        The policy constraints extension doesn't work as specified by
that=20
sentence anyway.  PolicyConstraints has only integer arguments, and
can't=20
be used to specify an Certificate Policy OID.  We might want to specify=20
that permitted-subtrees or excluded-subtrees can, at the RP's
discretion,=20
be copied to the corresponding variables in 6.1.1.  I do remain dubious=20
about the usefulness of CA's having excluded subtrees which are not=20
subtrees of permitted ones.
        We can't use the fields within policy constraints for this=20
purpose, since they're both bounded integers while the corresponding=20
variables in 6.1.1 are booleans.

        Tom Gindin




"Santosh Chokhani" <[e-mail]>=20
Sent by: [e-mail]
08/29/2008 09:56 AM

To
<[e-mail]>
cc

Subject
RFC 5280 and RFC 5055






1.       RFC 5280, Section 6.2, states the following:
?For example, a policy constraints extension could be included in the=20
self-signed
   certificate to indicate that paths beginning with this trust anchor=20
should be trusted only for the specified policies.?  This example should

be corrected to either point to certificate policies extension or to=20
relate the last half of the sentence to the semantics of require
explicit=20
policy.
=20
2.  RFC 5055 should be enhanced to align with 5280.  Aside from
replacing=20
the references, for example, inputs to path validation may also include=20
permitted and excluded subtrees.=20
=20
Santosh Chokhani
CygnaCom Solutions, Inc,
7925 Jones Branch Drive, Suite 5200
McLean, Virginia 22102
[phone]
[e-mail]
=20
=20



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m82CtoFs079513 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Sep 2008 05:55:50 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m82CtoVf079512; Tue, 2 Sep 2008 05:55:50 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.143]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m82Ctb9M079497 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Tue, 2 Sep 2008 05:55:48 -0700 (MST) (envelope-from [e-mail])
Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e3.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id m82CtR4X010970 for <[e-mail]>; Tue, 2 Sep 2008 08:55:27 -0400
Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v9.0) with ESMTP id m82CtG86221534 for <[e-mail]>; Tue, 2 Sep 2008 08:55:17 -0400
Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m82CtGkW001503 for <[e-mail]>; Tue, 2 Sep 2008 08:55:16 -0400
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.56.228.115]) by d01av03.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m82CtGKJ001495; Tue, 2 Sep 2008 08:55:16 -0400
In-Reply-To: <[e-mail]>
To: "Santosh Chokhani" <[e-mail]>
Cc: [e-mail]
MIME-Version: 1.0
Subject: Re: RFC 5280 and RFC 5055
X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006
From: Tom Gindin <[e-mail]>
Message-ID: <[e-mail]>
Date: Tue, 2 Sep 2008 08:55:14 -0400
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 8.0.1|February 07, 2008) at 09/02/2008 08:55:16, Serialize complete at 09/02/2008 08:55:16
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

        Santosh:

        The policy constraints extension doesn't work as specified by that =

sentence anyway.  PolicyConstraints has only integer arguments, and can't=20
be used to specify an Certificate Policy OID.  We might want to specify=20
that permitted-subtrees or excluded-subtrees can, at the RP's discretion,=20
be copied to the corresponding variables in 6.1.1.  I do remain dubious=20
about the usefulness of CA's having excluded subtrees which are not=20
subtrees of permitted ones.
        We can't use the fields within policy constraints for this=20
purpose, since they're both bounded integers while the corresponding=20
variables in 6.1.1 are booleans.

        Tom Gindin




"Santosh Chokhani" <[e-mail]>=20
Sent by: [e-mail]
08/29/2008 09:56 AM

To
<[e-mail]>
cc

Subject
RFC 5280 and RFC 5055






1.       RFC 5280, Section 6.2, states the following:
?For example, a policy constraints extension could be included in the=20
self-signed
   certificate to indicate that paths beginning with this trust anchor=20
should be trusted only for the specified policies.?  This example should=20
be corrected to either point to certificate policies extension or to=20
relate the last half of the sentence to the semantics of require explicit=20
policy.
=20
2.  RFC 5055 should be enhanced to align with 5280.  Aside from replacing=20
the references, for example, inputs to path validation may also include=20
permitted and excluded subtrees.=20
=20
Santosh Chokhani
CygnaCom Solutions, Inc,
7925 Jones Branch Drive, Suite 5200
McLean, Virginia 22102
[phone]
[e-mail]
=20
=20