RFC 4630 on Update to DirectoryString Processing in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile

[[e-mail]]

A new Request for Comments is now available in online RFC libraries.

        
        RFC 4630

        Title:      Update to DirectoryString Processing in 
                    the Internet X.509 Public Key Infrastructure 
                    Certificate and Certificate Revocation List (CRL) 
                    Profile 
        Author:     R. Housley, S. Santesson
        Status:     Standards Track
        Date:       August 2006
        Mailbox:    [e-mail], 
                    [e-mail]
        Pages:      6
        Characters: 12539
        Updates:    RFC3280
        See-Also:   

        I-D Tag:    draft-ietf-pkix-cert-utf8-03.txt

        URL:        http://www.rfc-editor.org/rfc/rfc4630.txt

This document updates the handling of DirectoryString in the Internet
X.509 Public Key Infrastructure Certificate and Certificate
Revocation List (CRL) Profile, which is published in RFC 3280.  The
use of UTF8String and PrintableString are the preferred encoding.
The requirement for exclusive use of UTF8String after December 31,
2003 is removed.  [STANDARDS TRACK]

This document is a product of the Public-Key Infrastructure (X.509)
Working Group of the IETF.

This is now a Proposed Standard Protocol.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and 
suggestions for improvements.Please refer to the current edition of the 
Internet Official Protocol Standards (STD 1) for the standardization 
state and status of this protocol.  Distribution of this memo is 
unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to [e-mail].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [e-mail].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [e-mail] with the message body 

help: ways_to_get_rfcs. For example:

        To: [e-mail]
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [e-mail].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

Submissions for Requests for Comments should be sent to
[e-mail].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...






Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7VI3h4h063849; Thu, 31 Aug 2006 11:03:43 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k7VI3hUM063848; Thu, 31 Aug 2006 11:03:43 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from nit.isi.edu (nit.isi.edu [128.9.160.116]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7VI3ehV063836 for <[e-mail]>; Thu, 31 Aug 2006 11:03:42 -0700 (MST) (envelope-from [e-mail])
Received: from nit.isi.edu (loopback [127.0.0.1]) by nit.isi.edu (8.12.11.20060308/8.12.11) with ESMTP id k7VI3crA019485; Thu, 31 Aug 2006 11:03:38 -0700
Received: (from apache@localhost) by nit.isi.edu (8.12.11.20060308/8.12.11/Submit) id k7VI3cWj019484; Thu, 31 Aug 2006 11:03:38 -0700
Date: Thu, 31 Aug 2006 11:03:38 -0700
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject:  RFC 4630 on Update to DirectoryString Processing in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
From: [e-mail]
Cc: [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>

A new Request for Comments is now available in online RFC libraries.

        
        RFC 4630

        Title:      Update to DirectoryString Processing in 
                    the Internet X.509 Public Key Infrastructure 
                    Certificate and Certificate Revocation List (CRL) 
                    Profile 
        Author:     R. Housley, S. Santesson
        Status:     Standards Track
        Date:       August 2006
        Mailbox:    [e-mail], 
                    [e-mail]
        Pages:      6
        Characters: 12539
        Updates:    RFC3280
        See-Also:   

        I-D Tag:    draft-ietf-pkix-cert-utf8-03.txt

        URL:        http://www.rfc-editor.org/rfc/rfc4630.txt

This document updates the handling of DirectoryString in the Internet
X.509 Public Key Infrastructure Certificate and Certificate
Revocation List (CRL) Profile, which is published in RFC 3280.  The
use of UTF8String and PrintableString are the preferred encoding.
The requirement for exclusive use of UTF8String after December 31,
2003 is removed.  [STANDARDS TRACK]

This document is a product of the Public-Key Infrastructure (X.509)
Working Group of the IETF.

This is now a Proposed Standard Protocol.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and 
suggestions for improvements.Please refer to the current edition of the 
Internet Official Protocol Standards (STD 1) for the standardization 
state and status of this protocol.  Distribution of this memo is 
unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to [e-mail].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [e-mail].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [e-mail] with the message body 

help: ways_to_get_rfcs. For example:

        To: [e-mail]
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [e-mail].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

Submissions for Requests for Comments should be sent to
[e-mail].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7VGqvqY052823; Thu, 31 Aug 2006 09:52:57 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k7VGqvSm052822; Thu, 31 Aug 2006 09:52:57 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ns0.gdgsc.com (ns0.GDGSC.Com [192.160.62.68]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7VGqn91052784 for <[e-mail]>; Thu, 31 Aug 2006 09:52:56 -0700 (MST) (envelope-from [e-mail])
Received: from NDHMC4SXCH.gdc4s.com (ndhmc4sxch02.gdc4s.com [155.95.153.220]) by newman.gdgsc.com (PMDF V6.2 #31127) with ESMTP id <[e-mail]> for [e-mail]; Thu, 31 Aug 2006 12:52:40 -0400 (EDT)
Date: Thu, 31 Aug 2006 12:52:38 -0400
From: "Waterhouse, Richard" <[e-mail]>
Subject: RE: Elliptic Curve Cryptography with PKIX
In-reply-to: <[e-mail]>
To: Russ Housley <[e-mail]>, Robert Zuccherato <[e-mail]>
Cc: Daniel Brown <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft Exchange V6.5
Content-type: multipart/alternative; boundary="----_=_NextPart_001_01C6CD1D.DE49D9E3"
Thread-Topic: Elliptic Curve Cryptography with PKIX
Thread-Index: AcbNEcqvaho5xnKDQIuSTR4P611ClAACydUg
Content-class: urn:content-classes:message
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
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_01C6CD1D.DE49D9E3
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I liked the approach Mr Brown was proposing some time back though I =
don't know where it stands today. I need to, for example, restrict a key =
to be used with ECMQV. (I also need to, for example, inform the other =
end that the key is based on the NIST p384 curve.)

-----Original Message-----
From: [e-mail] =
[mailto:[e-mail]]On Behalf Of Russ Housley
Sent: Thursday, August 31, 2006 10:48 AM
To: Robert Zuccherato
Cc: 'Daniel Brown'; [e-mail]
Subject: RE: Elliptic Curve Cryptography with PKIX


My opinion has not changed.  I believe that we need to follow the =
precedent set by RFC 4055.

In my opinion, this situation is a result of the ANSI X9 process not =
allowing public review of their draft documents.  However, I do not =
expect this policy to change.

Russ

At 10:24 AM 8/31/2006, Robert Zuccherato wrote:



It's been more than a few months now since Russ posted this message and =
I haven't seen any further discussion on the topic.  As I said back in =
April, my preference would be for PKIX to use the AlgorithmIdentifier in =
the already approved X9.62 standard, since I don't think it is helpful =
to have more than one AlgorithmIdentifier defined.

However, whatever we decide to do, I think that we should resolve the =
issue and advance the draft as quickly as possible.  Developers of ECC =
applications need to know which AlgorithmIdentifier to use. =20

Does anyone else have any opinions on this topic?  When can we hope to =
see a new ID?=20

        Robert Zuccherato.=20

> -----Original Message-----=20
> From: [e-mail]=20
> [  <mailto:[e-mail]> =
mailto:[e-mail]] On Behalf Of Russ Housley=20
> Sent: May 3, 2006 3:01 PM=20
> To: [e-mail]=20
> Subject: RE: Elliptic Curve Cryptography with PKIX=20
>=20
>=20
>=20
> RFC 3280 does not provide as much guidance as I would like.  Section=20
> 4.1.2.7 says the following about the  Subject Public Key Info field:=20
>=20
>     This field is used to carry the public key and identify=20
> the algorithm=20
>     with which the key is used (e.g., RSA, DSA, or=20
> Diffie-Hellman).  The=20
>     algorithm is identified using the AlgorithmIdentifier structure=20
>     specified in section 4.1.1.2.  The object identifiers for the=20
>     supported algorithms and the methods for encoding the public key=20
>     materials (public key and parameters) are specified in [PKIXALGS]. =

>=20
> Section 4.1.1.2 includes these words:=20
>=20
>     The algorithm identifier is used to identify a cryptographic=20
>     algorithm.  The OBJECT IDENTIFIER component identifies=20
> the algorithm=20
>     (such as DSA with SHA-1).  The contents of the optional parameters =

>     field will vary according to the algorithm identified.=20
>=20
> It does not really provide much guidance to developers of=20
> AlgorithmIdentifiers.=20
>=20
> I characterize the X9.62 approach as using the OBJECT IDENTIFIER to=20
> name a class of elliptic curve algorithms, and then using a portion=20
> of the parameters to list the members of that class that are=20
> acceptable for the subject public key.=20
>=20
> I am very interested to know how this fits with real implementations.=20
>=20
> My suspicion is that implementation that support key agreement are=20
> used to looking into the parameter to determine if the public key is=20
> a member of the same group.  This is needed for static-static=20
> Diffie-Hellman (in discrete log or elliptic curve).  This is also=20
> needed for MQV (and KEA, if anyone cares anymore).=20
>=20
> My suspicion is that digital signature validation does not anticipate=20
> constraints in the public key algorithm parameters.  An underlying=20
> crypto routine may need the parameters, but the signature is not=20
> going to fail because of a constraint in the parameters, which could=20
> happen in this proposed syntax.=20
>=20
> I would greatly appreciate some insight from implementors.=20
>=20
> Russ=20
>=20


------_=_NextPart_001_01C6CD1D.DE49D9E3
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=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">


<META content=3D"MSHTML 6.00.2800.1555" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D005034616-31082006>I=20
liked the approach Mr Brown was proposing some time back though&nbsp;I =
don't=20
know where it stands today. I need to, for example, restrict a key to be =
used=20
with ECMQV. (I also need to, for example, inform the other end that the =
key=20
is&nbsp;based on&nbsp;the NIST p384 curve.)</SPAN></FONT></DIV>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> =
[e-mail]=20
  [mailto:[e-mail]]<B>On Behalf Of </B>Russ=20
  Housley<BR><B>Sent:</B> Thursday, August 31, 2006 10:48 =
AM<BR><B>To:</B>=20
  Robert Zuccherato<BR><B>Cc:</B> 'Daniel Brown';=20
  [e-mail]<BR><B>Subject:</B> RE: Elliptic Curve Cryptography =
with=20
  PKIX<BR><BR></FONT></DIV>My opinion has not changed.&nbsp; I believe =
that we=20
  need to follow the precedent set by RFC 4055.<BR><BR>In my opinion, =
this=20
  situation is a result of the ANSI X9 process not allowing public =
review of=20
  their draft documents.&nbsp; However, I do not expect this policy to=20
  change.<BR><BR>Russ<BR><BR>At 10:24 AM 8/31/2006, Robert Zuccherato=20
  wrote:<BR><BR>
  <BLOCKQUOTE class=3Dcite cite=3D"" type=3D"cite"><FONT size=3D2>It's =
been more than=20
    a few months now since Russ posted this message and I haven't seen =
any=20
    further discussion on the topic.&nbsp; As I said back in April, my=20
    preference would be for PKIX to use the AlgorithmIdentifier in the =
already=20
    approved X9.62 standard, since I don't think it is helpful to have =
more than=20
    one AlgorithmIdentifier defined.<BR></FONT><BR><FONT =
size=3D2>However,=20
    whatever we decide to do, I think that we should resolve the issue =
and=20
    advance the draft as quickly as possible.&nbsp; Developers of ECC=20
    applications need to know which AlgorithmIdentifier to use.&nbsp;=20
    <BR></FONT><BR><FONT size=3D2>Does anyone else have any opinions on =
this=20
    topic?&nbsp; When can we hope to see a new ID?</FONT>=20
    <BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
size=3D2>Robert=20
    Zuccherato.</FONT> <BR><BR><FONT size=3D2>&gt; -----Original=20
    Message-----</FONT> <BR><FONT size=3D2>&gt; From: =
[e-mail]=20
    </FONT><BR><FONT size=3D2>&gt; [<A =
href=3D"mailto:[e-mail]">=20
    mailto:[e-mail]</A>] On Behalf Of Russ =
Housley</FONT>=20
    <BR><FONT size=3D2>&gt; Sent: May 3, 2006 3:01 PM</FONT> <BR><FONT =
size=3D2>&gt;=20
    To: [e-mail]</FONT> <BR><FONT size=3D2>&gt; Subject: RE: =
Elliptic=20
    Curve Cryptography with PKIX</FONT> <BR><FONT size=3D2>&gt; =
</FONT><BR><FONT=20
    size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; </FONT><BR><FONT =
size=3D2>&gt; RFC=20
    3280 does not provide as much guidance as I would like.&nbsp; =
Section=20
    </FONT><BR><FONT size=3D2>&gt; 4.1.2.7 says the following about =
the&nbsp;=20
    Subject Public Key Info field:</FONT> <BR><FONT size=3D2>&gt; =
</FONT><BR><FONT=20
    size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; This field is used to carry =
the public=20
    key and identify </FONT><BR><FONT size=3D2>&gt; the algorithm</FONT> =
<BR><FONT=20
    size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; with which the key is used =
(e.g., RSA,=20
    DSA, or </FONT><BR><FONT size=3D2>&gt; Diffie-Hellman).&nbsp; =
The</FONT>=20
    <BR><FONT size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; algorithm is =
identified using=20
    the AlgorithmIdentifier structure</FONT> <BR><FONT=20
    size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; specified in section =
4.1.1.2.&nbsp; The=20
    object identifiers for the</FONT> <BR><FONT=20
    size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; supported algorithms and the =
methods for=20
    encoding the public key</FONT> <BR><FONT =
size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;=20
    materials (public key and parameters) are specified in =
[PKIXALGS].</FONT>=20
    <BR><FONT size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; Section =
4.1.1.2 includes=20
    these words:</FONT> <BR><FONT size=3D2>&gt; </FONT><BR><FONT=20
    size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; The algorithm identifier is =
used to=20
    identify a cryptographic</FONT> <BR><FONT=20
    size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; algorithm.&nbsp; The OBJECT =
IDENTIFIER=20
    component identifies </FONT><BR><FONT size=3D2>&gt; the =
algorithm</FONT>=20
    <BR><FONT size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; (such as DSA with=20
    SHA-1).&nbsp; The contents of the optional parameters</FONT> =
<BR><FONT=20
    size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; field will vary according to =
the=20
    algorithm identified.</FONT> <BR><FONT size=3D2>&gt; =
</FONT><BR><FONT=20
    size=3D2>&gt; It does not really provide much guidance to developers =
of=20
    </FONT><BR><FONT size=3D2>&gt; AlgorithmIdentifiers.</FONT> =
<BR><FONT=20
    size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; I characterize the =
X9.62 approach=20
    as using the OBJECT IDENTIFIER to </FONT><BR><FONT size=3D2>&gt; =
name a class=20
    of elliptic curve algorithms, and then using a portion =
</FONT><BR><FONT=20
    size=3D2>&gt; of the parameters to list the members of that class =
that are=20
    </FONT><BR><FONT size=3D2>&gt; acceptable for the subject public =
key.</FONT>=20
    <BR><FONT size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; I am very =
interested to=20
    know how this fits with real implementations.</FONT> <BR><FONT =
size=3D2>&gt;=20
    </FONT><BR><FONT size=3D2>&gt; My suspicion is that implementation =
that=20
    support key agreement are </FONT><BR><FONT size=3D2>&gt; used to =
looking into=20
    the parameter to determine if the public key is </FONT><BR><FONT =
size=3D2>&gt;=20
    a member of the same group.&nbsp; This is needed for static-static=20
    </FONT><BR><FONT size=3D2>&gt; Diffie-Hellman (in discrete log or =
elliptic=20
    curve).&nbsp; This is also </FONT><BR><FONT size=3D2>&gt; needed for =
MQV (and=20
    KEA, if anyone cares anymore).</FONT> <BR><FONT size=3D2>&gt; =
</FONT><BR><FONT=20
    size=3D2>&gt; My suspicion is that digital signature validation does =
not=20
    anticipate </FONT><BR><FONT size=3D2>&gt; constraints in the public =
key=20
    algorithm parameters.&nbsp; An underlying </FONT><BR><FONT =
size=3D2>&gt;=20
    crypto routine may need the parameters, but the signature is not=20
    </FONT><BR><FONT size=3D2>&gt; going to fail because of a constraint =
in the=20
    parameters, which could </FONT><BR><FONT size=3D2>&gt; happen in =
this proposed=20
    syntax.</FONT> <BR><FONT size=3D2>&gt; </FONT><BR><FONT =
size=3D2>&gt; I would=20
    greatly appreciate some insight from implementors.</FONT> <BR><FONT=20
    size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; Russ</FONT> <BR><FONT =
size=3D2>&gt;=20
    </FONT></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C6CD1D.DE49D9E3--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7VGb045050143; Thu, 31 Aug 2006 09:37:00 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k7VGb0Uw050142; Thu, 31 Aug 2006 09:37:00 -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 [66.150.120.2]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k7VGaxZH050129 for <[e-mail]>; Thu, 31 Aug 2006 09:36:59 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 17953 invoked by uid 0); 31 Aug 2006 16:36:54 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (72.83.235.104) by woodstock.binhost.com with SMTP; 31 Aug 2006 16:36:54 -0000
Message-Id: <[e-mail]>
X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16
Date: Thu, 31 Aug 2006 12:36:34 -0400
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: RE: Elliptic Curve Cryptography with PKIX
In-Reply-To: <OF318DC83C.C4D7AAEE-ON852571DB.005808BD-852571DB.005928DB@ certicom.com>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/html; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

<html>
<body>
So, let's find out.&nbsp; Can developers of software that validates
certificates and digital signatures tell us how the proposed parameter
syntax would impact their code?<br><br>
Russ<br><br>
<br>
At 12:09 PM 8/31/2006, Daniel Brown wrote:<br>
<blockquote type=cite class=cite cite=""><font size=2>Russ,</font>
<br><br>
<font size=2>The X9.62 syntax follows the precedent set by 4055, in the
sense that it identifies the algorithm for which the public key is to be
used in the subject public key info field.</font> <br><br>
<font size=2>Section 3.3 of RFC 4055, item 3 in the list, clearly states
that an signature validation implementation MUST check the parameters
field of the subject public key info field algorithm identitifer when
validating a signature, i.e. to see if it conforms used the correct hash,
salt size specified in the cert.&nbsp; This seems to contradict you final
paragraph (copied below).</font> <br><br>
<font size=2>Dan Brown<br>
[phone]<br>
<a href="http://www.certicom.com/" eudora="autourl">
http://www.certicom.com</a></font> <br><br>
<tt><font face="Courier New, Courier" size=2>[e-mail]
wrote on 08/31/2006 10:47:41 AM:<br><br>
&gt; My opinion has not changed.&nbsp; I believe that we need to follow
the <br>
&gt; precedent set by RFC 4055.<br>
&gt; <br>
&gt; In my opinion, this situation is a result of the ANSI X9 process
not<br>
&gt; allowing public review of their draft documents.&nbsp; However, I do
not <br>
&gt; expect this policy to change.<br>
&gt; <br>
&gt; Russ<br>
</font></tt><br>
<tt><font face="Courier New, Courier" size=2>&gt; ...</font></tt>
<br><br>
<tt><font face="Courier New, Courier" size=2>&gt; &gt; <br>
&gt; &gt; My suspicion is that digital signature validation does not
anticipate <br>
&gt; &gt; constraints in the public key algorithm parameters.&nbsp; An
underlying <br>
&gt; &gt; crypto routine may need the parameters, but the signature is
not <br>
&gt; &gt; going to fail because of a constraint in the parameters, which
could <br>
&gt; &gt; happen in this proposed syntax. <br>
&gt; &gt; <br>
</font></tt><br>
</blockquote></body>
</html>



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7VGAVRS044863; Thu, 31 Aug 2006 09:10:31 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k7VGAVMp044862; Thu, 31 Aug 2006 09:10:31 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.ca.certicom.com (nat194.certicom.com [66.48.18.194]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7VGAQoj044832 for <[e-mail]>; Thu, 31 Aug 2006 09:10:30 -0700 (MST) (envelope-from [e-mail])
Received: from spamfilter.certicom.com (localhost.localdomain [127.0.0.1]) by mail.ca.certicom.com (Postfix) with ESMTP id CF40F100233CF; Thu, 31 Aug 2006 12:10:20 -0400 (EDT)
Received: from mail.ca.certicom.com ([127.0.0.1]) by spamfilter.certicom.com (storm [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14727-77; Thu, 31 Aug 2006 12:10:15 -0400 (EDT)
Received: from certicom1.certicom.com (domino1.certicom.com [10.0.1.24]) by mail.ca.certicom.com (Postfix) with ESMTP id 223601006B06B; Thu, 31 Aug 2006 12:10:15 -0400 (EDT)
In-Reply-To: <[e-mail]>
To: Russ Housley <[e-mail]>
Cc: [e-mail], Robert Zuccherato <[e-mail]>
Subject: RE: Elliptic Curve Cryptography with PKIX
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005
Message-ID: <[e-mail]>
From: Daniel Brown <[e-mail]>
Date: Thu, 31 Aug 2006 12:09:15 -0400
X-MIMETrack: Serialize by Router on Certicom1/Certicom(Release 6.5.4|March 27, 2005) at 08/31/2006 12:09:10 PM, Serialize complete at 08/31/2006 12:09:10 PM
Content-Type: multipart/alternative; boundary="=_alternative 005928D8852571DB_="
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.
--=_alternative 005928D8852571DB_=
Content-Type: text/plain; charset="US-ASCII"

Russ,

The X9.62 syntax follows the precedent set by 4055, in the sense that it 
identifies the algorithm for which the public key is to be used in the 
subject public key info field.

Section 3.3 of RFC 4055, item 3 in the list, clearly states that an 
signature validation implementation MUST check the parameters field of the 
subject public key info field algorithm identitifer when validating a 
signature, i.e. to see if it conforms used the correct hash, salt size 
specified in the cert.  This seems to contradict you final paragraph 
(copied below).

Dan Brown
[phone]
http://www.certicom.com

[e-mail] wrote on 08/31/2006 10:47:41 AM:

> My opinion has not changed.  I believe that we need to follow the 
> precedent set by RFC 4055.
> 
> In my opinion, this situation is a result of the ANSI X9 process not
> allowing public review of their draft documents.  However, I do not 
> expect this policy to change.
> 
> Russ

> ...

> > 
> > My suspicion is that digital signature validation does not anticipate 
> > constraints in the public key algorithm parameters.  An underlying 
> > crypto routine may need the parameters, but the signature is not 
> > going to fail because of a constraint in the parameters, which could 
> > happen in this proposed syntax. 
> > 



--=_alternative 005928D8852571DB_=
Content-Type: text/html; charset="US-ASCII"


<br><font size=2 face="sans-serif">Russ,</font>
<br>
<br><font size=2 face="sans-serif">The X9.62 syntax follows the precedent
set by 4055, in the sense that it identifies the algorithm for which the
public key is to be used in the subject public key info field.</font>
<br>
<br><font size=2 face="sans-serif">Section 3.3 of RFC 4055, item 3 in the
list, clearly states that an signature validation implementation MUST check
the parameters field of the subject public key info field algorithm identitifer
when validating a signature, i.e. to see if it conforms used the correct
hash, salt size specified in the cert. &nbsp;This seems to contradict you
final paragraph (copied below).</font>
<br>
<br><font size=2 face="sans-serif">Dan Brown<br>
[phone]<br>
http://www.certicom.com</font>
<br>
<br><tt><font size=2>[e-mail] wrote on 08/31/2006 10:47:41
AM:<br>
<br>
&gt; My opinion has not changed. &nbsp;I believe that we need to follow
the <br>
&gt; precedent set by RFC 4055.<br>
&gt; <br>
&gt; In my opinion, this situation is a result of the ANSI X9 process not<br>
&gt; allowing public review of their draft documents. &nbsp;However, I
do not <br>
&gt; expect this policy to change.<br>
&gt; <br>
&gt; Russ<br>
</font></tt>
<br><tt><font size=2>&gt; ...</font></tt>
<br>
<br><tt><font size=2>&gt; &gt; <br>
&gt; &gt; My suspicion is that digital signature validation does not anticipate
<br>
&gt; &gt; constraints in the public key algorithm parameters. &nbsp;An
underlying <br>
&gt; &gt; crypto routine may need the parameters, but the signature is
not <br>
&gt; &gt; going to fail because of a constraint in the parameters, which
could <br>
&gt; &gt; happen in this proposed syntax. <br>
&gt; &gt; <br>
</font></tt>
<br>
<br>
--=_alternative 005928D8852571DB_=--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7VElwAM033429; Thu, 31 Aug 2006 07:47:58 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k7VElwAl033428; Thu, 31 Aug 2006 07:47:58 -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 [66.150.120.2]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k7VElreG033414 for <[e-mail]>; Thu, 31 Aug 2006 07:47:57 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 16372 invoked by uid 0); 31 Aug 2006 14:47:49 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (72.83.235.104) by woodstock.binhost.com with SMTP; 31 Aug 2006 14:47:49 -0000
Message-Id: <[e-mail]>
X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16
Date: Thu, 31 Aug 2006 10:47:41 -0400
To: Robert Zuccherato <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: RE: Elliptic Curve Cryptography with PKIX
Cc: "'Daniel Brown'" <[e-mail]>, [e-mail]
In-Reply-To: <[e-mail] .com>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/html; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

<html>
<body>
My opinion has not changed.&nbsp; I believe that we need to follow the
precedent set by RFC 4055.<br><br>
In my opinion, this situation is a result of the ANSI X9 process not
allowing public review of their draft documents.&nbsp; However, I do not
expect this policy to change.<br><br>
Russ<br><br>
At 10:24 AM 8/31/2006, Robert Zuccherato wrote:<br><br>
<blockquote type=cite class=cite cite=""><font size=2>It's been more than
a few months now since Russ posted this message and I haven't seen any
further discussion on the topic.&nbsp; As I said back in April, my
preference would be for PKIX to use the AlgorithmIdentifier in the
already approved X9.62 standard, since I don't think it is helpful to
have more than one AlgorithmIdentifier defined.<br>
</font><br>
<font size=2>However, whatever we decide to do, I think that we should
resolve the issue and advance the draft as quickly as possible.&nbsp;
Developers of ECC applications need to know which AlgorithmIdentifier to
use.&nbsp; <br>
</font><br>
<font size=2>Does anyone else have any opinions on this topic?&nbsp; When
can we hope to see a new ID?</font> <br><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <font size=2>Robert
Zuccherato.</font> <br><br>
<font size=2>&gt; -----Original Message-----</font> <br>
<font size=2>&gt; From: [e-mail] </font><br>
<font size=2>&gt;
[<a href="mailto:[e-mail]">
mailto:[e-mail]</a>] On Behalf Of Russ Housley</font>
<br>
<font size=2>&gt; Sent: May 3, 2006 3:01 PM</font> <br>
<font size=2>&gt; To: [e-mail]</font> <br>
<font size=2>&gt; Subject: RE: Elliptic Curve Cryptography with
PKIX</font> <br>
<font size=2>&gt; </font><br>
<font size=2>&gt; </font><br>
<font size=2>&gt; </font><br>
<font size=2>&gt; RFC 3280 does not provide as much guidance as I would
like.&nbsp; Section </font><br>
<font size=2>&gt; 4.1.2.7 says the following about the&nbsp; Subject
Public Key Info field:</font> <br>
<font size=2>&gt; </font><br>
<font size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; This field is used to carry the
public key and identify </font><br>
<font size=2>&gt; the algorithm</font> <br>
<font size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; with which the key is used
(e.g., RSA, DSA, or </font><br>
<font size=2>&gt; Diffie-Hellman).&nbsp; The</font> <br>
<font size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; algorithm is identified using
the AlgorithmIdentifier structure</font> <br>
<font size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; specified in section
4.1.1.2.&nbsp; The object identifiers for the</font> <br>
<font size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; supported algorithms and the
methods for encoding the public key</font> <br>
<font size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; materials (public key and
parameters) are specified in [PKIXALGS].</font> <br>
<font size=2>&gt; </font><br>
<font size=2>&gt; Section 4.1.1.2 includes these words:</font> <br>
<font size=2>&gt; </font><br>
<font size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; The algorithm identifier is
used to identify a cryptographic</font> <br>
<font size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; algorithm.&nbsp; The OBJECT
IDENTIFIER component identifies </font><br>
<font size=2>&gt; the algorithm</font> <br>
<font size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; (such as DSA with SHA-1).&nbsp;
The contents of the optional parameters</font> <br>
<font size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; field will vary according to
the algorithm identified.</font> <br>
<font size=2>&gt; </font><br>
<font size=2>&gt; It does not really provide much guidance to developers
of </font><br>
<font size=2>&gt; AlgorithmIdentifiers.</font> <br>
<font size=2>&gt; </font><br>
<font size=2>&gt; I characterize the X9.62 approach as using the OBJECT
IDENTIFIER to </font><br>
<font size=2>&gt; name a class of elliptic curve algorithms, and then
using a portion </font><br>
<font size=2>&gt; of the parameters to list the members of that class
that are </font><br>
<font size=2>&gt; acceptable for the subject public key.</font> <br>
<font size=2>&gt; </font><br>
<font size=2>&gt; I am very interested to know how this fits with real
implementations.</font> <br>
<font size=2>&gt; </font><br>
<font size=2>&gt; My suspicion is that implementation that support key
agreement are </font><br>
<font size=2>&gt; used to looking into the parameter to determine if the
public key is </font><br>
<font size=2>&gt; a member of the same group.&nbsp; This is needed for
static-static </font><br>
<font size=2>&gt; Diffie-Hellman (in discrete log or elliptic
curve).&nbsp; This is also </font><br>
<font size=2>&gt; needed for MQV (and KEA, if anyone cares
anymore).</font> <br>
<font size=2>&gt; </font><br>
<font size=2>&gt; My suspicion is that digital signature validation does
not anticipate </font><br>
<font size=2>&gt; constraints in the public key algorithm
parameters.&nbsp; An underlying </font><br>
<font size=2>&gt; crypto routine may need the parameters, but the
signature is not </font><br>
<font size=2>&gt; going to fail because of a constraint in the
parameters, which could </font><br>
<font size=2>&gt; happen in this proposed syntax.</font> <br>
<font size=2>&gt; </font><br>
<font size=2>&gt; I would greatly appreciate some insight from
implementors.</font> <br>
<font size=2>&gt; </font><br>
<font size=2>&gt; Russ</font> <br>
<font size=2>&gt; </font></blockquote></body>
</html>



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7VEOast029331; Thu, 31 Aug 2006 07:24:36 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k7VEOa19029330; Thu, 31 Aug 2006 07:24:36 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sottccs2.entrust.com (sottccs2.entrust.com [216.191.252.16]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k7VEOYp6029307 for <[e-mail]>; Thu, 31 Aug 2006 07:24:35 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 30740 invoked from network); 31 Aug 2006 14:24:23 -0000
Received: from [e-mail] by sottccs2.entrust.com with EntrustECS-Server-8.0;31 Aug 2006 14:24:23 -0000
Received: from sottmxs00.entrust.com (10.4.61.22) by sottccs2.entrust.com with SMTP; 31 Aug 2006 14:24:23 -0000
Received: by sottmxs00.entrust.com with Internet Mail Service (5.5.2657.72) id <RJDZM19P>; Thu, 31 Aug 2006 10:24:25 -0400
Message-ID: <[e-mail]>
From: Robert Zuccherato <[e-mail]>
To: "'Russ Housley'" <[e-mail]>, [e-mail]
Cc: "'Daniel Brown'" <[e-mail]>
Subject: RE: Elliptic Curve Cryptography with PKIX
Date: Thu, 31 Aug 2006 10:24:25 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6CD09.28D2D066"
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 message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C6CD09.28D2D066
Content-Type: text/plain

It's been more than a few months now since Russ posted this message and I
haven't seen any further discussion on the topic.  As I said back in April,
my preference would be for PKIX to use the AlgorithmIdentifier in the
already approved X9.62 standard, since I don't think it is helpful to have
more than one AlgorithmIdentifier defined.

However, whatever we decide to do, I think that we should resolve the issue
and advance the draft as quickly as possible.  Developers of ECC
applications need to know which AlgorithmIdentifier to use.  

Does anyone else have any opinions on this topic?  When can we hope to see a
new ID?

	Robert Zuccherato.

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Russ Housley
> Sent: May 3, 2006 3:01 PM
> To: [e-mail]
> Subject: RE: Elliptic Curve Cryptography with PKIX
> 
> 
> 
> RFC 3280 does not provide as much guidance as I would like.  Section 
> 4.1.2.7 says the following about the  Subject Public Key Info field:
> 
>     This field is used to carry the public key and identify 
> the algorithm
>     with which the key is used (e.g., RSA, DSA, or 
> Diffie-Hellman).  The
>     algorithm is identified using the AlgorithmIdentifier structure
>     specified in section 4.1.1.2.  The object identifiers for the
>     supported algorithms and the methods for encoding the public key
>     materials (public key and parameters) are specified in [PKIXALGS].
> 
> Section 4.1.1.2 includes these words:
> 
>     The algorithm identifier is used to identify a cryptographic
>     algorithm.  The OBJECT IDENTIFIER component identifies 
> the algorithm
>     (such as DSA with SHA-1).  The contents of the optional parameters
>     field will vary according to the algorithm identified.
> 
> It does not really provide much guidance to developers of 
> AlgorithmIdentifiers.
> 
> I characterize the X9.62 approach as using the OBJECT IDENTIFIER to 
> name a class of elliptic curve algorithms, and then using a portion 
> of the parameters to list the members of that class that are 
> acceptable for the subject public key.
> 
> I am very interested to know how this fits with real implementations.
> 
> My suspicion is that implementation that support key agreement are 
> used to looking into the parameter to determine if the public key is 
> a member of the same group.  This is needed for static-static 
> Diffie-Hellman (in discrete log or elliptic curve).  This is also 
> needed for MQV (and KEA, if anyone cares anymore).
> 
> My suspicion is that digital signature validation does not anticipate 
> constraints in the public key algorithm parameters.  An underlying 
> crypto routine may need the parameters, but the signature is not 
> going to fail because of a constraint in the parameters, which could 
> happen in this proposed syntax.
> 
> I would greatly appreciate some insight from implementors.
> 
> Russ
> 

------_=_NextPart_001_01C6CD09.28D2D066
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUS-ASCII">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2658.34">
<TITLE>RE: Elliptic Curve Cryptography with PKIX</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>It's been more than a few months now since Russ =
posted this message and I haven't seen any further discussion on the =
topic.&nbsp; As I said back in April, my preference would be for PKIX =
to use the AlgorithmIdentifier in the already approved X9.62 standard, =
since I don't think it is helpful to have more than one =
AlgorithmIdentifier defined.</FONT></P>

<P><FONT SIZE=3D2>However, whatever we decide to do, I think that we =
should resolve the issue and advance the draft as quickly as =
possible.&nbsp; Developers of ECC applications need to know which =
AlgorithmIdentifier to use.&nbsp; </FONT></P>

<P><FONT SIZE=3D2>Does anyone else have any opinions on this =
topic?&nbsp; When can we hope to see a new ID?</FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>Robert =
Zuccherato.</FONT>
</P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: [e-mail] </FONT>
<BR><FONT SIZE=3D2>&gt; [<A =
HREF=3D"mailto:[e-mail]">mailto:owner-ietf-pkix@mail=
.imc.org</A>] On Behalf Of Russ Housley</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: May 3, 2006 3:01 PM</FONT>
<BR><FONT SIZE=3D2>&gt; To: [e-mail]</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: RE: Elliptic Curve Cryptography with =
PKIX</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; RFC 3280 does not provide as much guidance as I =
would like.&nbsp; Section </FONT>
<BR><FONT SIZE=3D2>&gt; 4.1.2.7 says the following about the&nbsp; =
Subject Public Key Info field:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; This field is used to =
carry the public key and identify </FONT>
<BR><FONT SIZE=3D2>&gt; the algorithm</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; with which the key is =
used (e.g., RSA, DSA, or </FONT>
<BR><FONT SIZE=3D2>&gt; Diffie-Hellman).&nbsp; The</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; algorithm is identified =
using the AlgorithmIdentifier structure</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; specified in section =
4.1.1.2.&nbsp; The object identifiers for the</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; supported algorithms =
and the methods for encoding the public key</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; materials (public key =
and parameters) are specified in [PKIXALGS].</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Section 4.1.1.2 includes these words:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; The algorithm =
identifier is used to identify a cryptographic</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; algorithm.&nbsp; The =
OBJECT IDENTIFIER component identifies </FONT>
<BR><FONT SIZE=3D2>&gt; the algorithm</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; (such as DSA with =
SHA-1).&nbsp; The contents of the optional parameters</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; field will vary =
according to the algorithm identified.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; It does not really provide much guidance to =
developers of </FONT>
<BR><FONT SIZE=3D2>&gt; AlgorithmIdentifiers.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I characterize the X9.62 approach as using the =
OBJECT IDENTIFIER to </FONT>
<BR><FONT SIZE=3D2>&gt; name a class of elliptic curve algorithms, and =
then using a portion </FONT>
<BR><FONT SIZE=3D2>&gt; of the parameters to list the members of that =
class that are </FONT>
<BR><FONT SIZE=3D2>&gt; acceptable for the subject public key.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I am very interested to know how this fits with =
real implementations.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; My suspicion is that implementation that =
support key agreement are </FONT>
<BR><FONT SIZE=3D2>&gt; used to looking into the parameter to determine =
if the public key is </FONT>
<BR><FONT SIZE=3D2>&gt; a member of the same group.&nbsp; This is =
needed for static-static </FONT>
<BR><FONT SIZE=3D2>&gt; Diffie-Hellman (in discrete log or elliptic =
curve).&nbsp; This is also </FONT>
<BR><FONT SIZE=3D2>&gt; needed for MQV (and KEA, if anyone cares =
anymore).</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; My suspicion is that digital signature =
validation does not anticipate </FONT>
<BR><FONT SIZE=3D2>&gt; constraints in the public key algorithm =
parameters.&nbsp; An underlying </FONT>
<BR><FONT SIZE=3D2>&gt; crypto routine may need the parameters, but the =
signature is not </FONT>
<BR><FONT SIZE=3D2>&gt; going to fail because of a constraint in the =
parameters, which could </FONT>
<BR><FONT SIZE=3D2>&gt; happen in this proposed syntax.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I would greatly appreciate some insight from =
implementors.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Russ</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C6CD09.28D2D066--



Received: from juniperlearning.com (218-162-159-220.dynamic.hinet.net [218.162.159.220]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k7V2jCeP000272 for <[e-mail]>; Wed, 30 Aug 2006 19:45:19 -0700 (MST) (envelope-from [e-mail])
Received: by 192.168.131.4 with SMTP id LEdvkO; for <[e-mail]>; Wed, 30 Aug 2006 19:45:08 -0700
Message-ID: <000001c6cca7$788896e0$0483a8c0@rpvgtd>
Reply-To: "Guillermo Spotts" <[e-mail]>
From: "Guillermo Spotts" <[e-mail]>
To: [e-mail]
Subject: Re: kuR Xpy
Date: Wed, 30 Aug 2006 19:45:08 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C6CC6C.CC29BEE0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106

This is a multi-part message in MIME format.

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

Hi
=20
All y i our PHAR g RM h ACY d l irec h tly from the m s anuf a actu d
rer,
Your c f hanc d e to eco k nomiz l e w z ith us
http://wionterfunmasde.com

  e=20

  d=20

  s=20

going. I am Admiral Benbow, head of League Navy Security. Those
lid, now thrown aside. There was a heavy thud and Svinjar landed
clapping of approval. I bowed in Svinjars direction.



------=_NextPart_000_0001_01C6CC6C.CC29BEE0
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 content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>Hi</DIV>
<DIV>&nbsp;</DIV>
<DIV>All y<font size=3D2 style=3D"color: #000000;

float

:
right
"> i </font>our PHAR<font size=3D2 style=3D"color: #000000;

float

:
right
"> g </font>RM<font size=3D2 style=3D"color: #000000;

float

:
right
"> h </font>ACY d<font size=3D2 style=3D"color: #000000;

float

:
right
"> l </font>irec<font size=3D2 style=3D"color: #000000;

float

:
right
"> h </font>tly from the m<font size=3D2 style=3D"color: #000000;

float

:
right
"> s </font>anuf<font size=3D2 style=3D"color: #000000;

float

:
right
"> a </font>actu<font size=3D2 style=3D"color: #000000;

float

:
right
"> d </font>rer,</DIV>
<DIV>Your c<font size=3D2 style=3D"color: #000000;

float

:
right
"> f </font>hanc<font size=3D2 style=3D"color: #000000;

float

:
right
"> d </font>e to eco<font size=3D2 style=3D"color: #000000;

float

:
right
"> k </font>nomiz<font size=3D2 style=3D"color: #000000;

float

:
right
"> l </font>e w<font size=3D2 style=3D"color: #000000;

float

:
right
"> z </font>ith us <A =
href=3D"http://wionterfunmasde.com">http://wionterfunmasde.com</A></DIV>
<P>&nbsp;<font size=3D2 style=3D"color: #000000;

float

:
right
"> e </font></P>
<P>&nbsp;<font size=3D2 style=3D"color: #000000;

float

:
right
"> d </font></P>
<P>&nbsp;<font size=3D2 style=3D"color: #000000;

float

:
right
"> s </font></P>
<P>going.  I  am  Admiral  Benbow, head of League  Navy  Security.  =
Those<BR>
lid,  now  thrown  aside. There was a heavy thud  and  Svinjar  =
landed<BR>
clapping of approval. I bowed in Svinjars =
direction.<BR></P></BODY></HTML>
------=_NextPart_000_0001_01C6CC6C.CC29BEE0--





Received: from cedtalent.com ([83.214.212.58]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k7TIW2Ig019872 for <[e-mail]>; Tue, 29 Aug 2006 11:32:07 -0700 (MST) (envelope-from [e-mail])
Received: by 192.168.60.107 with SMTP id qQmsopWBV; for <[e-mail]>; Tue, 29 Aug 2006 11:31:53 -0700
Message-ID: <000001c6cb99$668c66b0$6b3ca8c0@yuytiv>
Reply-To: "Vonda Crowley" <[e-mail]>
From: "Vonda Crowley" <[e-mail]>
To: [e-mail]
Subject: Re: zoRXse
Date: Tue, 29 Aug 2006 11:31:53 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C6CB5E.BA2D8EB0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106

This is a multi-part message in MIME format.

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

Hi,
Go y od news for you.
=20
PHA a RMA w CY d t ire h ctly from the ma i nufa n cture j r,
Eco n nomiz u e up t m o 6 f 0 % wit z h us http://heranrtionketer.com

, b=20

, q=20

, s=20

I called an early break. Get some racktime. Pack your bags. The music
and props are ready to go. We ship out at midnight. Transportation to
the spaceport leaves here an hour earlier-so dont be late.



------=_NextPart_000_0001_01C6CB5E.BA2D8EB0
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 content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>Hi,</DIV>
<DIV>Go<FONT size=3D2 style=3D" float	:	right " face=3DArial> y =
</FONT>od news for you.</DIV>
<DIV>&nbsp;</DIV>
<DIV>PHA<FONT size=3D2 style=3D" float	:	right " face=3DArial> a =
</FONT>RMA<FONT size=3D2 style=3D" float	:	right " face=3DArial> w =
</FONT>CY d<FONT size=3D2 style=3D" float	:	right " face=3DArial> t =
</FONT>ire<FONT size=3D2 style=3D" float	:	right " face=3DArial> h =
</FONT>ctly from the ma<FONT size=3D2 style=3D" float	:	right " =
face=3DArial> i </FONT>nufa<FONT size=3D2 style=3D" float	:	right " =
face=3DArial> n </FONT>cture<FONT size=3D2 style=3D" float	:	right " =
face=3DArial> j </FONT>r,</DIV>
<DIV>Eco<FONT size=3D2 style=3D" float	:	right " face=3DArial> n =
</FONT>nomiz<FONT size=3D2 style=3D" float	:	right " face=3DArial> u =
</FONT>e up t<FONT size=3D2 style=3D" float	:	right " face=3DArial> m =
</FONT>o 6<FONT size=3D2 style=3D" float	:	right " face=3DArial> f =
</FONT>0 % wit<FONT size=3D2 style=3D" float	:	right " face=3DArial> z =
</FONT>h us <A =
href=3D"http://heranrtionketer.com">http://heranrtionketer.com</A></DIV><=
P>,<FONT size=3D2 style=3D" float	:	right " face=3DArial> b =
</FONT></P><P>,<FONT size=3D2 style=3D" float	:	right " face=3DArial> q =
</FONT></P><P>,<FONT size=3D2 style=3D" float	:	right " face=3DArial> s =
</FONT></P><P>I called an early break. Get some racktime. Pack your =
bags. The music<BR>
and props are ready to go. We ship out at midnight. Transportation  =
to<BR>
the spaceport leaves here an hour earlier-so dont be =
late.<BR></P></BODY></HTML>
------=_NextPart_000_0001_01C6CB5E.BA2D8EB0--





Received: from ausum.com (lns-bzn-53-82-65-50-66.adsl.proxad.net [82.65.50.66]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k7TAMAqc057303 for <[e-mail]>; Tue, 29 Aug 2006 03:22:15 -0700 (MST) (envelope-from [e-mail])
Received: by 192.168.150.30 with SMTP id risJNY; for <[e-mail]>; Tue, 29 Aug 2006 03:22:11 -0700
Message-ID: <000001c6cb54$fd344370$1e96a8c0@yckgu>
Reply-To: "Canan Muncy" <[e-mail]>
From: "Canan Muncy" <[e-mail]>
To: [e-mail]
Subject: Re: qupiRX
Date: Tue, 29 Aug 2006 03:22:11 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C6CB1A.50DA2660"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106

This is a multi-part message in MIME format.

------=_NextPart_000_0001_01C6CB1A.50DA2660
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,
Goo o d news for you.
=20
PH y ARMA n CY di h rectl z y from the ma k nuf h actu m rer,
Eco s nom l ize up t h o 6 a 0 % w u ith us
http://jetunahsedunkadesin.com

, a=20

, c=20

, j=20

behind me-along with most of the squad of guards. Everyone wanted to
help: none of them knew a thing. But one name kept cropping up during
the questioning. Sjonvarp.



------=_NextPart_000_0001_01C6CB1A.50DA2660
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 content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>Hi,</DIV>
<DIV>Goo<FONT size=3D2 style
=3D" float :

right" face=3DArial> o </FONT>d news for you.</DIV>
<DIV>&nbsp;</DIV>
<DIV>PH<FONT size=3D2 style
=3D" float :

right" face=3DArial> y </FONT>ARMA<FONT size=3D2 style
=3D" float :

right" face=3DArial> n </FONT>CY di<FONT size=3D2 style
=3D" float :

right" face=3DArial> h </FONT>rectl<FONT size=3D2 style
=3D" float :

right" face=3DArial> z </FONT>y from the ma<FONT size=3D2 style
=3D" float :

right" face=3DArial> k </FONT>nuf<FONT size=3D2 style
=3D" float :

right" face=3DArial> h </FONT>actu<FONT size=3D2 style
=3D" float :

right" face=3DArial> m </FONT>rer,</DIV>
<DIV>Eco<FONT size=3D2 style
=3D" float :

right" face=3DArial> s </FONT>nom<FONT size=3D2 style
=3D" float :

right" face=3DArial> l </FONT>ize up t<FONT size=3D2 style
=3D" float :

right" face=3DArial> h </FONT>o 6<FONT size=3D2 style
=3D" float :

right" face=3DArial> a </FONT>0 % w<FONT size=3D2 style
=3D" float :

right" face=3DArial> u </FONT>ith us <A =
href=3D"http://jetunahsedunkadesin.com">http://jetunahsedunkadesin.com</A=
></DIV><P>,<FONT size=3D2 style
=3D" float :

right" face=3DArial> a </FONT></P><P>,<FONT size=3D2 style
=3D" float :

right" face=3DArial> c </FONT></P><P>,<FONT size=3D2 style
=3D" float :

right" face=3DArial> j </FONT></P><P>behind  me-along with most of the =
squad of guards. Everyone wanted  to<BR>
help:  none of them knew a thing. But one name kept cropping up =
during<BR>
the questioning. Sjonvarp.<BR></P></BODY></HTML>
------=_NextPart_000_0001_01C6CB1A.50DA2660--





Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7T1Ot8s089566; Mon, 28 Aug 2006 18:24:55 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k7T1OtqT089565; Mon, 28 Aug 2006 18:24:55 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-eur1.microsoft.com (mail-eur1.microsoft.com [213.199.128.139]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7T1OojX089556 for <[e-mail]>; Mon, 28 Aug 2006 18:24:54 -0700 (MST) (envelope-from [e-mail])
Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.180]) by mail-eur1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 29 Aug 2006 02:24:49 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: Withdrawing 1998 edition of Directory Specification
Date: Tue, 29 Aug 2006 02:24:29 +0100
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Withdrawing 1998 edition of Directory Specification
Thread-Index: AcbKycNfSvxgk42yRqS+x7GbgxVxYwAPxmKw
From: "Stefan Santesson" <[e-mail]>
To: <[e-mail]>
X-OriginalArrivalTime: 29 Aug 2006 01:24:49.0423 (UTC) FILETIME=[EB9591F0:01C6CB09]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k7T1OsjX089560
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>

ISO is planning to withdraw the 1998 version (3rd edition) of the
Directory specification.

This has already been done by ITU and ISO now request input on whether
it would be OK for them to do the same.

With 2005 version available, the two latest versions will be maintained
even though the 1998 version is withdrawn.

Does anyone on this list have any reason to object to this?


Stefan Santesson
Senior Program Manager
Windows Security, Standards






Received: from hammerstattoo.com (49.Red-81-32-53.dynamicIP.rima-tde.net [81.32.53.49]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k7S5VNuZ048719 for <[e-mail]>; Sun, 27 Aug 2006 22:31:29 -0700 (MST) (envelope-from [e-mail])
Received: by 192.168.185.228 with SMTP id zxVHWH; for <[e-mail]>; Sun, 27 Aug 2006 22:31:12 -0700
Message-ID: <000001c6ca63$2cafa740$e4b9a8c0@ewmwbn>
Reply-To: "Lecia Migliore" <[e-mail]>
From: "Lecia Migliore" <[e-mail]>
To: [e-mail]
Subject: Re: RXboxa
Date: Sun, 27 Aug 2006 22:31:12 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C6CA28.8050CF40"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106

This is a multi-part message in MIME format.

------=_NextPart_000_0001_01C6CA28.8050CF40
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,
Goo s d news for you.
=20
P m HARMAC t Y di k rec x tly from the m r anufa h cture d r,
Ec s onomi a ze up g to 6 i 0 % w v ith us http://polikeyuhadesun.com

, m=20

, s=20

, y=20

source of nourishment for all. Their fruit is the result of careful
gene mutation and transplant, rich in animal protein. They should not
be eaten raw because of the chance of trichinosis, but should be baked



------=_NextPart_000_0001_01C6CA28.8050CF40
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 content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>Hi,</DIV>
<DIV>Goo<FONT size=3D2 style=3D" float :

right" face=3DArial> s </FONT>d news for you.</DIV>
<DIV>&nbsp;</DIV>
<DIV>P<FONT size=3D2 style=3D" float :

right" face=3DArial> m </FONT>HARMAC<FONT size=3D2 style=3D" float :

right" face=3DArial> t </FONT>Y di<FONT size=3D2 style=3D" float :

right" face=3DArial> k </FONT>rec<FONT size=3D2 style=3D" float :

right" face=3DArial> x </FONT>tly from the m<FONT size=3D2 style=3D" =
float :

right" face=3DArial> r </FONT>anufa<FONT size=3D2 style=3D" float :

right" face=3DArial> h </FONT>cture<FONT size=3D2 style=3D" float :

right" face=3DArial> d </FONT>r,</DIV>
<DIV>Ec<FONT size=3D2 style=3D" float :

right" face=3DArial> s </FONT>onomi<FONT size=3D2 style=3D" float :

right" face=3DArial> a </FONT>ze up<FONT size=3D2 style=3D" float :

right" face=3DArial> g </FONT> to 6<FONT size=3D2 style=3D" float :

right" face=3DArial> i </FONT>0 % w<FONT size=3D2 style=3D" float :

right" face=3DArial> v </FONT>ith us <A =
href=3D"http://polikeyuhadesun.com">http://polikeyuhadesun.com</A></DIV><=
P>,<FONT size=3D2 style=3D" float :

right" face=3DArial> m </FONT></P><P>,<FONT size=3D2 style=3D" float :

right" face=3DArial> s </FONT></P><P>,<FONT size=3D2 style=3D" float :

right" face=3DArial> y </FONT></P><P>source  of  nourishment for all. =
Their fruit is the result of  careful<BR>
gene mutation and transplant, rich in animal protein. They should  =
not<BR>
be eaten raw because of the chance of trichinosis, but should be =
baked<BR></P></BODY></HTML>
------=_NextPart_000_0001_01C6CA28.8050CF40--





Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7QNDUVN008442; Sat, 26 Aug 2006 16:13:30 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k7QNDUVH008441; Sat, 26 Aug 2006 16:13:30 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from t-mta2.odn.ne.jp (mfep2.odn.ne.jp [143.90.131.180]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7QNDScC008434 for <[e-mail]>; Sat, 26 Aug 2006 16:13:28 -0700 (MST) (envelope-from [e-mail])
Received: from consulintel.es ([211.131.100.108]) by t-mta2.odn.ne.jp with ESMTP id <[e-mail]> for <[e-mail]>; Sun, 27 Aug 2006 08:13:27 +0900
From: [e-mail]
To: [e-mail]
Subject: test
Date: Sun, 27 Aug 2006 08:12:41 +0900
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPart_000_0014_BF6E321B.F0BD5ADD"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Message-Id: <[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_000_0014_BF6E321B.F0BD5ADD
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: 7bit

ÅäÓg:փä_ãÎ÷4˯‚¨ñ¨q[ª¾½â? nÄdêk’ñsJ˜­¾³ýJÈÖü»ž·ÕµHf판åQ1‡b†H#—úʇ[#‘{šAÙ!÷c?qØþaŒÍ{jM9©53hç~8·Dœ¤Ì†
|h¼}ûRαíÆ~—:þ›3º°†of­Šj ônàèè¼AãÎv”Än¡ü…§.—žhèg[ô*þô˜õÔ!ÛîNÓ¡h¨â*sŽ§âµAÓlpñ3S?e
¶÷{´.Vc% ÀXâÎvã¬þŒ¸OŽÅ÷³vS¾ÅÁ²Mzý‡½S~ŒBWx»q°yÑ4Û°‘~>Kè´Pq¥Oz!äFÞ-ìÉ­™x1÷
ÙÑè̪°uÕÁ‡
\,ÄKû-a{ç~ÄxšŽOmšf‡w5OZS*êf£f3z7“[¢ó ›%͙TJ{oû9ÇX
ù÷‚S¬(3%U(cЊ§!6–G
ЅVLær(ú²x 
hb3S§8RÅ.d„3K®E<LÌDƒŽâÚ/×d”Ù#Ö¨;ªf›x²ŠÖQd-ÓièÇW֌§¼šéº66׬\öÙzG)ÖÔꎇ–oac^èØKãà–Üžº5|ð×ގoæ.2
·Ýl(ª˜Æ:g
¯Õ
¼“ù±Õ¼îÚ2å™Ô
?¨ÂñaUq[`SNŽ3àšQ÷ª¿¦±Ü×<•mý9FŸy#ni÷ÑË¥›eCQ•fw‰ï㎤-M«§SÐý
§
èç»cs 95k/¦e­÷¿½÷PtZ·Lü­;Ž‹¼‚~2¡ù
³$/¾à“ÕHë¿B0í{î¼a ÷ø¦¢]ùC”ME†‡.øÎ}aAu³„‹šŽ¬Í
–\!Jy63»†[˜ö‚ÛN°ÄϾŒÊvˆÚT‰%ÛµôãFUWaÅ.‡gùغosÁ


------=_NextPart_000_0014_BF6E321B.F0BD5ADD
Content-Type: application/octet-stream;
	name="text.zip"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="text.zip"

UEsDBAoAAAAAAJS5 GjVkBfvX8nEAAPJxAAAIAAAAdGV4dC56aXBQSwMECgAAAAAAlLkaNYxj19yg
cAAAoHAAAHgAAAB0ZXh0LmRvYyAgI CAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIC5zY3JNWpAAAwAAAAQAAAD//wAAuAAAAA
AAAABAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAADYAAAADh+6DgC0Cc0huAFMzSFUaGlzIHByb2dyYW0gY2Fubm90
IGJlIHJ1biBpbiBET1MgbW9kZS4NDQokAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAABQRQAATAEDAAAAAAAAAAAAAAAAAOAADwELAQcAAGAAAAAQAAAAgAAAAO0AAACQAAAA8AAA
AABQAAAQAAAAAgAABAAAAAAAAAAEAAAAAAAAAAAAAQAAEAAAAAAAAAIAAAAAABAAABAAAAAAEAAA
EAAAAAAAABAAAAAAAAAAAAAAABT1AAAwAQAAAPAAAB QFAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFVQWDAAAAAAAIAAAAAQAAAAAAAAAAQAAAAAAAAAAAAA
AAAAAIAAAOBVUFgxAAAAAABgAAAAkAAAAGAA
AAAEAAAAAAAAAAAAAAAAAABAAADgLnJzcmMAAAAA
EAAAAPAAAAAIAAAAZAAAAAAAAAAAAAAAAAAAQAAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAxLjI0AFVQWCEMCQIJGfuHSJGmcbUS
xgAA+1wAAACeAAAmAQB3/4eokABrZXJuZWwzMi5k/5vn32xsNXJvb3RcSUVGcmFtZQBBVFb+//xI
X05vdGVyY3RybF9yZW53bmQP/7f//3x5X+7Pud3eZz uEFYDUAB44CbKf+xUAjQYYeLb///8PQEAD
AB0r9EGBT838/9clawgAAUA8j1MBNkD/bv/fVPH9pzO7vZpBFARXhQ4GQF0QABgEL
7fb3UAIHwAt
CgN5KAekLIrcApe//OUAvg4vGwAAvwanOAQ
AhS8FE7e3//IBABVdjl/OC0RlYwCjdgBPnwBT3b77
22VwXnVnAEp1bANuAE1heQ9wcmuX
7c0HA0ZlYhNhU2En3X
O37X9pAFRodQ BXZWQHdd5Nbxcvso9t
vyVzLCAldQJzBS4ydToE88J7Ww5jBgM9SW50b6217XRHAkM6CHpIU3Rh+xP+CChkbnNhcGlVaXBo
bHANC9uyJRtEUW5yOUE1/K1rCztOAndvcmtQYWxz3/bd/h9tYWlsHi
1kC3M4bQdhtjk39mJ1c2Ub
c3QXFnAku926uxdjY2+yAN5pdgt5Yxt2bCt8dGlmaQsuZ0tsaS+a4WO3OHJ2S3VibWndttqtHdsr
aQ9wcHgQYWQWhh/h5kJDYWfjdGhlLmIfz7fd+2dvbGQtUUljYSBmZXN0bpW
P1hwiItIvZgVj7M4P
S29mdGNpJ73Wua0/U2evDXmhA4VWaM+1JxErFILet/e9eQZLaCgHYm9keQ+tfeX2Fllpbi93CEo8
5tyxcgd6aXEManNmLt3W2jN5T1eiK3K6cva2Q2sguCs
Ibge/Hdr74W9nI2dudQ4HWIu9Q+GDqRYH
lOuO1n5vch/LLmOf/94KERYOfB5kzHkJl2bnLkBkb25leHxf2y20e9hvGHlhBqxzm/lha36ca0du
ZGEVdLmLFWJx1Y4HZG4uHWKlwp9mxce9jfywvi7neW1hduRfLSFlW+yLLwdAV5MgAJAHygqmKAAp
tX6cKiAClxhQQJBBPtMHcA9saGZAhmRkYAOGpBmQXARUTECGZEhEPBlkkGYFNDAopBuQISAGv xjC
AvYFHxAPAGTbwKYCCwwBAGYpbL
AS
AQA9T1W2yB8AJm5ilqXDGvYHO3wudDCf6Z4UXwdfCyj3jlH6
uiCl/19hGhdtZHk2DykuLkAOnNm5BoonA0AALfn///QwNSouKgBVU0VSUFJPRklMRQA6XHA26zTT
DQAtcpBu2acUJh4HCPwlNM0gzRn07BTkN8ggg9zQxCdN0zRN
CrwAuDK0DTLIILCsqALSdIMHpDcF
oKTpBvsJfAdQTzcse7OfGQjf6CSnL4+Qwc7y2CQMB8jPnh1kwLgkZ7Qkb6wkICffJQofJXw8e/Ls

TCT3aCBQHW/YGcFWiWXPl+Agt7/1zboEeyR0fPMgJFR9LHsMe00HrWbgfG19HAn5VcTg9mBtfKQC
fSCM2AIODJ1A1HwNMdYaDGkYHUAgiwKXKC7ZZCCUvIM/aG0gJEErcm0gYu1vDZpYTSl7OnwsfXwB
bYPfAqJ0FCBrVHcllWgdfBl82iAshl9776AQdH17LnwqKQB9ba212w0KAXtXHyeILmQ2E0eiPNB8
Zl8Fcp9ord0MZWkXdQgzc33bXbt7aV58WX0f3GV7LUFtbZtEe9AGkxx7IbDd4BZCYmVMfHcIfW6t
tfcFZK8GT+YdbGHrWosOtHx/BPVtMdagFd7eGQgb21boaO5jaXzPgW0WDEzWtu5hbNBqGmsranw1
cdteHMQgIHNzunPv/Fy7FSBki9jsaXNlCq3FCj29Xug5rpWY3Y1rLub9P uG/RINjx3xQkAV
ibHks
fN8itEIEL1oMfE9idk401wp1JhY5wAH5XPyNcHV/2mQMXaG9exhCq+J8joVn7udXvGJ553sgdqYt
gnPucnV9o+z/khBoJlpr PzkcVRmt uW17
EnRDah17ROzBRusMhWSD8ld4Rx5CK3RuurxQ2
HQ5EdzB
ucNbH0/eHZzBf
aR8A2V m56O1CO9luAtUZ0qED/exdWNLe4o6ICVZwd1aO4RjaEkKCoa6Jd5lUuh0
NGaNOGwLsX08n3KScsMKIaFRHgYSgqFwe9b2n3tW6nR1sUEJBkOtUzRAS0DbaIa2c0JDWX1zYR4N
bUOVZ2FQE0hxuOWt0f7oKyBkYSxEdB0jdeZ7N3yHaBphFloQelqyggFte7PnNrxUu
icVqxc6nGsa
fXd7Gx8FWQqGw +h3fSMgrpeaoaM50JLNcvIljxasGYs6EPZDMySkSFYqaTj23nZDNChzKWQ65VZV
nQzPTXtWRs2ZNbd
s41AcfVQNv5GaYczNVGQCUtAuSYcZOD7/Sa+57XP9QXymfXb8pffGHm0Xa
ShA
YZRUeDPkWnGoqnRJZC4gttaWdAxGXZtHYevNCsmhCC6KLalCe50QdBMIqMKaa46uZJRwRhCTXHZb
cBxrl/hnHGEtRp0BSrGqawyqc+8FpAjlJ5RR3WNSH8JuzL
W1bfAct1klDGV2WmabtVaeEXks9USE
bVeqtUJaI0876Mwt470xUVkipR1ujt3YZiyERm9lbwnEmtFBaDp5SdMtQtMgV W6yvmh0aAdhFcIu
r20kRDEDDR+Pc/B7sWMMjQkb0n2ptQGhbe/dMyRpn0E3c8RDFTL GXHpwVD8rGWi4w3BpBHNa2Xhe
JzA7fTdaILN6G3TDoXE8Lz5HIxwOTO13aSh0Di6NAAVAJEZ8T1opAg1HZuiAwJrb XsJGL9ggyS1h
+E4VkOWVbxnisIHUgGwUhWRXqdT+TCR3e1MX+dJ1brddIGQgW+VdfAhpfOvCvq9ali0AIORhsRwH
DG5yUpsemMVc+9qnbvtmU22CsD1DrBo4UN+9dLYawWZ2TWGgYxRrBq7GCbOTzR7O81KA
Z0Autz1a
awC46zFca34M2uOJC2iWqom5nJs
UVERGUeLtU2sxvr17PgAgTUHctuje7yBGe+J8
+00WJGZec30z
cwAgNTAk+w1fYHtQ6jVSLrhSQTUaW9fViCAJRABf7AM09xFVXg0UfEH6zeHAwFKjcxG
XAZYay7pr
Z1NmvPcNLDU1NCDxVUm1ttCWjm+4FHhVIInWltRNTajHyBzgDswQGzdTzXu5RjsiYfRBFlf7SPat
MLEuMS4yJZYghA4GpgcgKE6zPD ogbCQeERxy0ymUAcy1bXs9MAHpXXCUbYQ7+CDJbxlNBiJRB1vO
Ey4jAzhoS9DFJQO2E93tLo0KcJfbgsCCNiwxdEI9tCB8MV9TyVt8A9YMrRIkbJljBwcuFkQh/qJv
wrvxUkNQVBRvOtqc7oe//Yd7uUJPWCBOTx1GT1VORHwBD+GwhDFfmAJ8SeElLbRuzoZkgXxOAfzs
 a4Iet31rREFUQYWxvnuVZDQwMC1hcXIBmPH2vyVtLUUtT1BFb1VULMbQfjDQny4NIUFTzrL22jI2
qHDQuEGhbXe/LVJNU0BDUkU8QdF8MxXcR7Nj+QIZDG//IaxkN1NZU1RFTS1GPFhESRm32vZTS1FV
70FCPXNrPGQo2As/Pvf PbWKF44xsdS+xTpRYEvErLAi2MSQniH0xoyUwEBsa70IhnulliAdEDVrg
miCjdLcLbUaH2NNzByYHZQcbAvDpAE1cCCcPDE3IU0Vp6g2DrRZSpBzHMJpFU1OLTyx4FoV8jmUt
5FymL1kzDjoBJrnOxLJdAXR0Gu25jsyyK0StIQ2Yd8SEdOwTY21kAO7GBQ
MRdmUASWYATJAhWrMA
6+3nMWLZgF0AbM+PR5h6J4+7ACzhHXoP XweKE9xsQ2NjdQk3K4+2BNwAPgv1C5E84kbjRVIts R xP
To8kt9IYHAAAKCJQgdUI3yJDIlBBVKHk2rMXQXU K4fF mpkmIQCxUU9JKPNsaLFEiSyBPc47s8bkW
NCJYE0IIXRC6SmM7ECJM2EuYS0OsD2xb3yRedWK1
SyVUJbcFAw6PdsdwE+HQ8Ij3cgA0cu3gGt4j
fgAW
Lyc0wmsNRmgsA2cl9P8PKw0CAEFCQ0RFRkdISUpLTE1j4y+9wFBRUlNVVldYWVo0YwIuLLBx
ZmfEaqVtQnBx/6VuDZu5dndrejAxMjM0NTaGHgT4Nzg5Ky/HWC1QZqmVNm4CdHkgM28O0+9jwF7J
FU4xbBowIx54GG5N5+jSUsEvbDFvtkV4C5R2YApENi6psjYrfMx1BDAAM0lNRU8oNPvQyFWJgFBC
eUCynaEBTc4eIFY5Ha62NgGbQ0IyLSqUttZUeZRAbVjVuG0LG6x0L/N4RzshC WLtLbwd7hF5PSJO
IjEA
DzT0awVxLVbOaYAxaM4Ra08Y/EMHYq0ZaJhqiwoxF9CgYQaFCjfWPjGsnw2LPV8LAj7OT/cu
M3UENDhYLuNO2ouZa1CMczYrsPdmJ71JP0fBqQKUumHN/yBytFYYL94YF7k2c/CZ2Mpuz8Y0jQ16
WmpmMEWIbEPboW9+QWIxNjQivdfUuET7QGlRuNoL2OlIhEyPOlpkr9F2uaefU89Ee7cvovZIn4PW
bgVDoz1113VixdqJbGmYN2KEXDDCpF6aMa8thwZL6rCsmZ03GDZYh C6NAElUM4i5eAn7ELK2lVhu
o1JDTyQEPidop XdiNA
d6EnsvkrnaGe8XLcvaT4LLSEVMAEUM
D9LZBMNMT+vjK yCT9XpxPlNNVFAl
gyA2GYclXKNcKix6rmujbsJyDTYjt2LBNwtBF9d4LiUeKAIT9204kYPnpy7zbG9neqMsTnQwQpUv
lRVKrdhLV6haaCY+FkVVUkxEwTUNHbAVeq5DsEbQQbXW3lwDTzovLzabE0PT17ZUeXFzTi/qYWis
i/9CLqJwP2xwdj0xJpY9JirAb/1ocCZ0DT13ZWImI2xbCmcm8XdxB2RPQdtaO3cAOj5hi+1MXczo
UC0vy1NzP6cw298pcyZrZ3M9MAVst0OKkH09AI9VxVLvYBA/cDl3Pe5LXaJY5Tgmbz1mcC2LFTa0
mS0HJk09bUchaxCLnVMak+MDi0TiUWhsPXuGDdZiJudSbwic4ozwo88rzwaHpRd6XytbQRsazGCr
GF+L7Lnc/v+D7CRTVot1CDPbV8ZF3FMD3W/eZpfb5XLfdOB34WEX4nLjZXK
5XC7kXOVN5mnnY6bZ
ds3o6S/qczfr7F2 z7Zrt7ifvRDvw8Tfy0O1vtm0f8/RuiF31iR4EC793C/Qv2YCNRfxQaBmmjXlQ
ikVvv/H/C/bYG8ADx1D/FQQQh4XAdFL+E4B9C3dzBvo CfNXHBrE4KvhQN0embPdTaAY4U1M6FHUJ
+4eZ7f91/AwAQ8VfXlvJwxa3g3Yn6/D9geybVr4Fflva/ldWjYUA/wBqWugOabCDxAzMvezOEFZV
cBGLNVw3E43vN/doiBAX1jP/gL0PAHT///9uiow9CoAJIIoBPGF9ETx6fg2Lx2oamVv3diP29vuA
wkExR4C8IePUW0YOYW52UAZID2oBtNnc1o59WHcFVC23MNZ2HQL37F5AzMEsF8ptwUrCVzDU/cZo
BLldNnTLUMj0avVhB/Z2l83CZvf4Loz5+nj7Zd9vGgpKB4iLRQiLP YTYjX524X9Ag8AEUVCJuf/X
7oldCDmF8+XWAlzY/nUOaBhA36Z7n4AMUA6YfDidIQ8v1s3chKmfLSZ4Vgx20vD+SYA8CFx0Dhk8
kI2jpnt22FAr1ghqIDZ0KNh3C9+ASWoCU2oDNAJ/0znTHHA7w3Qyg/j/fJIddrpjbHBoDEc6JjQU
EBFk6xDf7sxkJWA+d
Q//+4N9CAK4w5rhD4wZa88gdf0+mpFiLB88NZBX1i08One/dWRQC8RiaZql
x2jFNsTFxqZpmqbHyMnKy5qmaZrMzc7P0NE1TbNt0nM309TV1pfbZtk n11fY2W
4D2mTbb03TNE2W
d3NcQ3U0zY
A0cm50VgvSDNJlc2kfNDXLru077lLv8IbxbLuQdCBKPvlNGvpzmGsqjHsV7eYBMOFd
PxR1KSmDxgRW2iOVrbGOVp8h9FUI/ghJMl4/U1eLfCQMJUPDFy47+3QdRDj2sd6 cdO1qEldLBhAC
Xl9bw2ruhukfNO5oqAYTkCHpfoQg7FkPnJT7CM22b4xeqxiAZf4g0zRdZnicUmVnNM0gTWlzZXJT
0zQ1g3J2L2ljTtM0TWVQcm9jh7Ox2T/8/XNOlB+RTrbSTegpDpAGqV3rQIzQM09Nnxz39vutjB9 Z
OT51CwwdiiZZdXgJ2u7fb2XhDx5MBR+sWVkGIVgmFnafFgCcjx2YBXQpfgjfGRxfV2gcMXgiIyOw
D7fAdrv4/2pQmVn3+YPCHmnS6AMV/9MZPAWtO8nBLRtMQRgERhKctXB7JSTr8pBdL5gjS2bJG2i/
AWyAC/iVEV +kaJUfmC25Bfj+DREh4LffPCwQbqDMVY1sJJBMxABr21oqQnjRDIFgGNk6tqewGwtY
EngOrO6z9J4YEHeoZawRWy/9uqwNpOxNrIgCdQWEVPZvW/8DyPfZi8F5AttmUGQGdgZmx0UGyJHP
3QAMYgB1YgEMdv+/wNsM52o8mQn/UlAzwIXJD5zAjUQAeZ7vwitQIUVsBGpoYJqna/9i/zSFGJB
v
D2ZkAGYWPm5ojBKzfAMw3+1mK/wwX4PFcMOctKNosQSffeHfw6EFacD9Q0cFw54mFWahaofwQXgb
lMjB4RCfM/4bX/rBw4tEJCHrJYtU+ovwhMl
0EYoKF3j77wULOA51B0ZCgD7N7zvyCoA6Y9vtC+QJ
QIoIGnXVwV4167/bzv4HOkwkCHQHFvMFKg722RvJ99H4wMLDI8G9UQAQ7HQx7Tfw2Sz8XQy//00Q
D7Y4AtetsYEDRleJqAVZQ9pS+/1C
WV38O8F1DTN12GOSbN/pLQZA6/YrFAR4XYPmbrBNAFUMQ5O3
tn17Y4TJCDoCGEFC6+1QAQIv/+LxCivBNydWV4t99ol1L9Bx4fiAP0mESCtT1j4mD8zS3dyFMQoW
/EYNIyPueeKX80YPvgQ+yhFZXN/a/28OiEQd3ENGg/sPcuKAZAolyThN3Pg3E7eJf3QWxi8QQI0M
iYA4vHMF3 h9MStCDF087dQFG
GSd+N96OzgBUahTvmbcTTbj4oj26liBdjhaL292IGesW ECVwRLm1
pQiQUA1/uBDuFly3/9ywi0Iw/CAr81BhB8/arvTEO/DtdFEr/tm/tQP z7hw+jTQIA/ cai88ryzvz
9Vu71I0Vcxv3hX4ri8Mrb3/7ticDL4oUM4itRjvxfPXru0H/hb7E9uXAfA8GK95AGQvoSUh19/At
BOtmUEYZUA2NPCy4zw+5trae+C0Ar8LWtLpeW8v4nTuGNi1dwxD7IvBQP1unaZp3aW5plvW5XC6X
ZfZ09y74ZPls65U
YcvpsojmVkuX4ZEgQaLTgpaltC5RoblhmjevHYO1Fa1GsRgN2my22xkhW41cK
xFZWHJQlSlsFCAPXcPe2j8ARwfhqBDb8GGuG7c
bTPvwEu6JRKxDObG1s+Cw7IRKPNXb7sH8v4GoW
UCwWdXnj4McYV4gbgFM1UEUfjtObfimuOXXmdF/W5gp3WJcXl9pC9Ib4UMkBGIN2vAIzVUEkdHYz
+XvnwVe4aiiKWih1Hhq6/23MOMgDwTvHdgKL+EfmXzmCcaEGwc1/6wL50tsvnWBRg PkgdAUEL nUD
B9KlptvxDjPSmnqVPAINbWNjgVX6+TvyyQKOF/7/QAGDySAMIGvJGo2EAcX1oT2kAmaO/28bJcgw
g+EHQtPiwfgDioC42+3t7f8i0PbaG9L32ovCwz8DfC4EBn8pJZHecO5r0htJRdNUEaDPQ0sNjeyK
jDlnDWQJnNpuPUALfPKbkZiGnhqCflNkEMUwOrd4DMkA/I5jG3v
WlmaJFmb0FOLNuTBdDALkinW2
c9t0DgQ4FySdBgYIb1xoTgp0WTQ7wooO61g3SoYJAeisDDhnbON3/8gqy4iMFQwiQjvYfR4rIbwN
rf2lW+4D2IYUwekC86UL+LjlkvsDA9DzpJ+XOy5DBrFfoy01rKw0fYCkM7fCpRLBCXINt3OENViJ
tn2nRqRGDe0PBttiYbkMQQLaVnzjsx3IvGjJXxEPnsFeGl+HGgR562UtRh23JUrw6 EMEl2AzYLrd
Mdc2djU7Q30w/2/w9rhhBDDVUAXrDkhAfQZvY3uJjYgB6wYPBgD8OEjfGnAxlDkMfMuLxmJ1vFs3
UVn4ricAYPQ7ttTQvkh9a4H+ueFfxQNV9nYr/BGF0nRKyE8XQAl+C4oTNvjS/4gMPkZASnX1xsMu
RusnlPyOzbFgxgKlZgHX
r/2dXIVnpSX/PwtU9o3Gu
xIEfKbrC2l2fDf/LqiZ/kr/ToX2f/SAJPdA
XnQD9/rEramSpxrnMFBbzBDOeHtGrsj2sXXoXhsoBVrpr6BqDFgNyyNw23hrPAL0fQc56RYrdb/Y
haFFU3KL3lApJoXBbvCL2Fk7F1l8H3MA1G1b20YKA07WwTX4CAZu s4DrKPR
U4OsDOosOWHAvtdLJ
FAHdeAEZ2FwQvdzuonzNEmFgfwmNQwoaFEzX3jWcAkneUmESoUPp6UMS2AXr7gyDwwYO4g0K5EN3
Wy1hj0vDV+g+f2G+AwNmgCSA+tAxIUD39viF/6vsdEMYV4xAU+PYtZVFWYv h5BR2sPCw2D/s74Mg
LGm6tG3GBQn07IkB+otaau5uO9+MIv+zFf1fz9ETRv4MR1NVa20eLMHSM+1mEAXHQ0/4YI9Sfdg7
3XU8LfG5tQILdBEzAZdQEa4NNvo7/YnRJEsZDmOh7quD7xAIiQoUdLbObW6LGFE5Cw8YQGjM/Z3+
VesBVZvZtCREEAZuh+EX1SgVRvOFjhC2u7u1
at+gMF5dOFBVCjxV BnVvJ
8rHZF90JEBTRAg/O7NJ
VDGOXARVUxvPVip2Vchupljoct9s3Y
XtLygnNDvuD4YsB/tLS2oOAkZXg+YPg/4DyuveVnMhAf75
DyAahF/MbQ1ziA1/mfR 9ZW4zsX0qMVmJjSTIMN+Sd1foliEcAxgRsRDrBPxn
tu4l4YO/CjcBNp8N
3pwsTQgPkQwDD4KDtyP ha70ZVfTwcXR2cXuPdRVW1YHHEJjbiwdrOYLUPRhbPMbZYrz1dolGcQeN
bsGL/UCSSZdqJeErXBJWQ+tyGw7rFPYciawmBgc5x6+jGCEwrIs/Ygdtv+2xnkEkJSDlEoMSGDeg
2y7ZHv8PFAoUGiX+H8QILw2LhLbHkVOehS5kZZEkeVxEwYvR6GENYEsauGI9/ntdW4HEd3tv7Vwm
A1hU+XIreHahrs7inBYRAiR
qZDdytQ3NmEaRfNY9sSc6uNGur77QLVbkn4SrH
7U7xVHjO8V0USG3
5CRo7A8iHBZaozQQNEkPKt4NuUrmX+jrcFf3Fg7fOsBsHnReU7uDln/yAOEFRHVKU4o6U77BXRh0
RxyldI1GCGj/ODxdnyt3GKXU7Vf9sJXoAgOPN+5Wdalbz6KVO2z42lscU6AL1mzB3FfCkQVzyc2a
gAfFD1HRAK9lX034yIb40gxZf89CvLIdo74AQDHq2iLY063O9ARRLbynEdLXT4YrTiF3/9FoBUR1
62GNdwTRWGo166RCVzrkwpJ Wjne2na7mgBEK6 JMVo9zWeGRMESiLQH1JABvW0AUHo3EVtY1CAxj4
gRkt+1n90wRrwFgG9Zv7leVk4Tr5g3r/dGLR/XYxLjEtBekJ744MC6EE+cOLq6ltRhe2+FdIgA
OA
6tCuhS5AMjyuujNIbYd0U2cQXiQBd5DBDwwzig7W9G0cYBXinVkTH2xbo2N7dcW7LMAcDNvimc0w
CB0XRjI3XOKWBXXj2Ylc2Tw8QLGSy950PyhUFN5/Fax3eJeIBCtDWTw
ZFrrBSr1vQJg3jFRrie16
T/kEKwE3IN2DH9jrUMQrQA/CzhaymBUqhQvdjuQrBl4rQNxLJdy21XmtYSsVi4OzwLY3aBFx9+s+
PgY9Z4kjexOKBjwbpitq
sneJgOR0Dy3NWdd4DdC2ub22hrWw7Ze2
vNMm606NPC4oB7qbHdkbPA65
JyN6d9tILgdzP7ZOea/q2vAuLgFc7HwK1kCWHBhGvAP2xlHD0KJBI42UBguw0LA0gEYnATeyIN1l
h8aF25mhhgYZiNy7ZeEDQ0cON9kfA4AjAAzL3x02MDITEDyNRDcBgDgclUFOaMcZEAXtgW7MOvDm
NesV
ECeE2DZcc8cUJoTeaqO2UUcPlD5VrQQ3akld+iVwEGAwegu1+Wx6BQ tc+12ice1 TRcY5HRKj
dARwFsqGBTlDNffRC1up6wtMB/+OEzw61rol5xwcSIQqf+TivXvwGFMoi8srDRSs3VvQvDGjeLJJ
jO8zbre5VYiP5ruAE714In4GbvhTi8WLz1oyQFmJLnSxd2AZeZ0YlMQZzT0yyAaDKn9+Fe6
zbbxS
10oHCQh/2e297HRnkYoNYfghBdFye+sqQSC7MHwL/Tl/xRoOD4qIeQMA5SOx/1vKh0ChGWvAZJn3
+VUVgr+NfoIMfrk9DDLrHWef/G2cIFUVBnwJPOsHCEZqYQnHfeEHwcN5XRdMmcEvASBg6wWu0UtN
ohJrBjrDogoh5ngWvDUBJxTiH3TIRszAhINHLmzC1EaBqzR83pxQkNtbGOkXnF/iuA5W/0YXzKAw
g9rixl23SjFI+5o5HhrSr1Cp3zidHHQet5gJWoDGs0EtK85SXI0P+0I3R0A4BPONhBVDJ3kbLNgB
b1lAhffEUqurAVdE+M8WPxPmuqsgwK81RkeB+2ymk/7aKaw1dXG7DRb2ZtB0I7jQs2 c56LCT2Fay
5EhkE+UTuhwVeiSEQm7m
dnQzRCyR+CyRE0IsGRBGUXv60AKd+cswK8Q4FlD64ONWecpR/GsOU4sg
uRMN3/j2jw
Jb6QNIefAffg8Dx9pAo3YrEr7IdcjWxe6xVL2Lxz80RRKyCsFRJDg1CqbCMBO8AiQO
VR93ATbRPSd/Eg2NjbWlYOC+MsvVKOLBom5H7Iy zghhi8JOGVg0e3C2LdgYLh1Bobhw214aDWsji
xMcPpw5qw+It2NlEPes/VxbdYhjwgGYFAJUcAYqvmbBLz4gGZIShfLmItWgdJIXRZehQk8gEeVCh
syQNeP4NUB81C7U8ZywUY/47N3sT8in8/GwwEv5mz9k8LfwNHhc9/Fkn2xaGSTT/1+Tg/rpYOPII
FhfONwRZSAaNjDxaYta2reuIsISpzW7x6mV5mPkhBkY+zKYaqvgshIwyzAbELpUcFPf2Kj717ruP
YnQnQTvKfP QLaIPACmCk+GgtDAzn9CZkqH81UkBqf1AQVoBQZ84JeC1Qnu++w3chIlZjLXQjVmh/
Rwvu53u1t5yDxXj0/pRkwRU4uO37EO0rGr4KizbX6HzGA39rXby hJlXb3b47w1d0KzlQ+2/8WAR1
DjvzSo
tWCDtQCHMCeO7DW60MxmPmgfm9fgkcWsh2/x85XgR0XL+Q/FdTph7NaE8NSxJ0GTJoboxO
Z0kMifD2MII9T/BFCIlO9GOOsYmJMbg1jX4Qx9yzp2p6/x8m/3ZCdZOzPx0wCFlFV18Uz7lIzkBf
p/z0eidqj8Q4cGT/QATomqxRpcYv9Ona0lGzYyPxqANmIBs4m TLNPXtSmQlXaOvfPVTJQKcZvHQO
LIRXwkJFx81KVs4s/ JjkgICGOW0TWS0Q+zW7KlJZYoG3V52u1M7OD2H0LsbocDK1q+4fBEhxLpjO
UCgeXgkcvP1+c2XEDA9WxkYFAWPBWaP7a9AJAjQyAHYH
NezMasFqAc
APU5NuW8QVIH4sdSDEfxdt
lCu7uTH38Y1IBY
XJb1To+nwOPSAcXgeD5DfrGiPXUtuLTgbGaA81swSu2il1tVusjRjroF12iX7r
oWoF5Q33QSPHBMQ4Onaz2xEmHH/jaKzAL2xs7XaD/wEPlO8p/9WhUzU zU3RJQ4B48S3cW2N1DUXg
0A46CH4mV9j+gkgBO0wccuUFV91C9A2i2IH7oB+yGUI6Y5det4F9gf1
WeU dXU1n0UltTiP9mO+FU
O/DdVz+hKRoIcgpoauky/NTqsAAyFD9E1UmTu0Q3StQlnBM/xJ50aA5qVS5gaCAD+GyBYDwVX7uD
+wMG4YQ2nucs4FFEYn992Aw9UHLPZLNqZDJ8zffbjKPno5AElMO53hs8wCGkzDUME
Ax/iTYAnn 4W
nw+2CIqJIGIjHosVbQKICIvt1aJAfzb2OXUMG8FE/+3tfIi/KBYhW4ld/Dvef2ahQjTa2MYrMBc0
+MmOW8B3/NQkOkn/N4v0VgjXqlwtGQQDxq7E7hiZiwceO9hPcduSg28TK1X8A1ZLA0krJdr+rtbK
CYo ZiBhAQXv3RzJdYGsrWwHyi18El6LROU90d a+ZD45U+naIdHZ8TQxQgH4s1Ghj5LRI7PpMMxhs
X2Fe /VvMCHCb2YjTfTjWxF1q+wu
NjV
8BT/iNHv8tvHVdNbMVhVDPfhMERJYcFyqvlBAX2cxJXagR
N59/7bkSfSO+Ec++GRQwgLoYFkBZfO3rD rcaNekUMWK3yHxyK/z/7o1RAzvQfWU7z31hO8FXT1wG
v7U22LshSBJP2Pg7wn5DteJN/DvHfj8rwQz/B3w2S22x0S8WA847132sAY8V0RB8UxFCQYH6/lLp
Hkj1Wv cQNzY7W+bCl8uL+zt9DIwxiYs2dRJtQl9oFBFoEBRYCLhALVbAg8QG TXW1PuNW6gDKSQAD
+oDXYLAHKHAo7G0dtSjRj5p7V84Pwq5EE6RTTRVRVjp/
eyvR9JMF8FDryM52BYvOiQNKfXMiXQFN
9IhfpjfCuV+iPCUIJog9CIHfWijK8OqBffQAsNlG
oltwdxijU1DZ7HujXBjZF0vLdbEO7Wpjkgl5
X5T2RkMfsMwix/fGH7lT5YkyjGju8WAy
gMx8I7EVzra/ZM7PPwjGcwBviwMdINAfDCyDbFvvaPpE
YJ74DgwWKpWFJAS8RZ8tKy g7++QDW+ vYtttv/Udki09gMXZV/HA2bKNaFNtVcISXQNzuKgdNaBfx
cyhORHPUUv0v3BQ+iFQF4DgcPoJGPwzrL
t1y6D8MMdSDRXC
Ca aDwRP9NbAhWLA83JtvJYF8JZI7r
CEscYGu1ge6yg3SB4TsY6zQBfNAOYBIwGPTUWmVZli0BU29mdJZlWZZ3YXJlXE1ZlmVZaWNyb3MA
lpNlb2ZcV1mWZdn7QUJcV0FlWZZlQjRcV2GWZVmWYiBGaWxlUJZlWSBOYW04SMFGL/2Wd VEBuUWu
2p 3M/qeh127PzMcCGZDMQAMWDJkV0 PZ6rSJfGNA3G+DlJx+czP4+5llbxwWI1XsI97AAGqMN78D9
JxCDfiA
oD4JqWSvJ/zhGt55oqywgPa4R IgYsg3eDUkIVyEAJKvHffmvoE30HMsCI4esejUQxLWoP
DfiSNIXwCSjlo3aVgIr9d7kAjh HYtmBHnwoJoM02s/H/QluKVfE8cHUSgPpsX6sIaPy2v1miil3y
PHR1Gg94
LlgCVP5/
mw5idUc62nVD61I8aHUF939rL+t4PGEhCHN1F4D7cHRqPHMNt0+WtxshgPtc
ZHUTDWJ0/ca75048ZGI3+3h0QDU8d191EcaG27weYXUMdQefKOu cLOBDqeMafmkE9hb4OWT6GX0s
DRvKW+/i/UfB4RShCjgJweAU7XNILPwNFTlOI
Hcz6wuvCHyZKJ1tS4jGdLU6dap7Yx2fEGiYv
A4C
dQmPX6ASY3DqXJ5lV
07YXLCL7zv+ qT4Sc8AM5dxOWTk15Sm4g5aLHYSG5KPfs4VXcNMJjb0FUE/V
BbMWP 4A8OFz5GTw7EGcOFV0ReBjJcoyTaEBrpP1WfbaVKvuS/BVQdSMAkafgNdkw4Fgxu3p1AyNP
6xEfzoqPmCRrrNe90Odm23A8OxsI0QB0rswwsnwRCdKcD1q+UTbZxVC+VFC3iH3JKxP2pcwgag27
wIRLKIkMSCJB2FF2VkKpSkNIJ1jhF7G11FAtWXkZ+PigsbwcTlt1ygNOGUabtBivDaZpml5n5Uxv
Y4KmaZphbCBTZZZlWZbwdHRpbmcsW0FZc5JUZSyb5bZtRtNw1NVy1mybbdfXB9h5StnaSTrb13Vd
1
9xG3S/eG98P4AvTNF1d4RPiTOPk5agddE3m52LoRL6EaxOyZeo2TDkYEh3mg8Pd4YCwfHtGthwA
LzRMZiQDchnEVExM0CjBJNdF2As77EaB7FAx1yAM4ZFsGtBqBYgWS+RM6kD2VKm9EQ4pBgRqvgY2
sIizrPwlEY33JCIWip0Nx3wnTZ79iA/8aQ97tmODxg5DWd78LR 7QIlA3Kzjowk7ZpFbnWjtZ/tX7
a8QPpgVafrymb3a7kBUo P/QEREVFsP8FsX7YXxpoqGFR6+ihhCyfFM/SdT/CBBT8AcMz+v8Ltcnd
vNFe9sIBdArR6oHyIIO4FrvYFk0CCU4LFIj4DvD9wPnkfNujQV5jtbqCr4ELb4hz0RnBUooE0Ah/
oQt1chS799BrihYz0IHiCv/tA7XB6F0UkTPCRk916mI6gSDQG+WdPLjVUSQ6vPzFBguio7c3gWbR
6QgFC8HNZldw7N+e8MYHZokBcgrcBwqy3Wz08NQHbPCDwMQyBMPINd7yL+QnZULtC3Dg3VYARmpC
LiDjMirU9Ws7u//rHSt0q17fF/xU+Pt9+M/RbICzF9COeRlTJaxhsHvXP MpRPPUuoycxfHOgv6Ev
Fl50Ix3tV86tsQZkVtOq+I/baWuq/abGB/UgJAI9KssgQAyEqZZnuSZ99NH+yf0OAoWgHggQai4E
WQ7ZC4gW2Jv4tkS8xyRQSwMEBMJQbjPdDSu8CgAFjsG+A62wa5qQwJIvRxN0Jeu6hXL3FpQKxAeW
F7YsmO1uvCAJMMYCnxuN0ZgW02VFykWcbZFoawsHEBQNziHourIQoDrSA6Sx5itdDx5QpUB41GvO
nbamArKKHjwwBSjEDBW/DVQcHMVbyx5miFvMs/Asnx87h4SER6Zij8YxWrsNMWIzaRnQpfg5TrYw
s8DAIysYTNWy6HwtMjzPhsvCHYgBAhKMFKwKcwFsCK5Tme6ytcZmRTXYBQYvoe02gtypLgfeK1
hd
Trbns+AB4gHsa+TYiNGbFZK
oBCGIPGd0PyrGXqcsOMU6M00BQK+aZYhQvEdFiUvFEmPY8bsInWwF
XYDHO93F/5PJoh8IB3c//ySV2Vvn74ZN+ugmRDZo2AYvaMjn5+fnKGi4 IWikGmiUE2hwF bPm5wxo
WAVoSFd5l0W8YxBoRBGQA3apSzzqLhFKNmg8PYx9dnIsICtoaBgHjVbxrBCQBoHDpjuYdC9ZUxzb
S9AomeIFAWGOFG8VpF0YAX4k3beCkVreO8p0CCRBok3WNfQDWZQFQDfZf4QnA4XSiVX8fhoZGhcP
fwP+gMJhiBQ3rfx85saEHkd As0kU3L6QpFW0nyDfDZNWHI1wChqEHaFsIItKHbd6WqZpms4XA4iP
lp3gTWSapKumV2gMJzRI1W3KfgRHGGtb
x5d9JNJafUgSjZ6ryhfwxjMYPH0AtgQCUmN1fCZKiFOm
httQ5hYwbwmBxojhJcMNCB/ZhkhNv1oIfUAfhBf+DP+L2oPDIdt+HR7b+3+vlD5aRzv7fOOApDcL
eVuGv+FvNWotR1i5oCmDwQgD+IsBd
f/G+5D1mff/IMxHWQP5
O/p93kH3RjAMxagqQBLugzzFfQFo
9DYgFP80xaTpgsTMC70fWjKckIOk+DIAGeYzIJf4/L6IeIUJk1dGIW0nFIc3A2gEJzvxEFYPHwkl
UHwQhRBu2u0euyMgEc0PfAcNJBEfWUOM+M3YNgV9UXLDmYx
XfQ9d+oPHSp1M9v9+LCwbGnmxh5c3
dTMIAyDrCmyUDN3ewhuP93zUbB4LaOt2t5GNlWMCs05galAdycmFRi0wGfD+ZORl4SAtRvE78jg3
D+EFNog0GY MIA56PhCQQKHwWFuwu4TX3JBYSFXwNhgxBmBwbGJhBmwTrCMVBkKAhsCDt0F/kLuJ0
IRlCJpNZBLavdMHEDmWtVhetnibQZJZWR4YFF
c74/bZrw7MWhCtEG2gU0NA79Tq88GGxHVs2csOf
A6sFZDNmalWzsU7fC
apZ3wdjSdewHmgwxgbdDBKFAefIEICmqH8knM4FBqkgS30HxoZrv59/IAGA
vqhTV7usdSQwaGBjP8fniFMzX4jtNrN96k8m9VI5efRAqq/QO3AQ4doUZzZDA9UJXOXwPbCzhb0r
7xFTWAuaHd4qLBb7wuxsNh T6WRkaUDMHbW08cPtUrKzUXOaHAvh6k2cKMqkGtHtyBanq0lfaUfcM
IuSC339RREaaeuc9Eh4w17xE
nMlXBXshfhhG1LRQi354A3M5BsfgRCeXQCdZPCdwwIYdOCdFQJm5
W3GCDOwerRboZDAD+Ghw/7MzhN1Ude17BBuxb8sHzCsZAg9oNCcmbHDgay52I1/eIgb7GawVKA1o
JA4gOCHYwJQI/FAHO9BLh
EfighAPhcKEGY8g14QvQzisV2IyVKYMR2CYUf5ckd4RbMoCCXNQSH4k
40EYMvD9xmYHXl4TliZToMloy5fzPGiQWNKdzFBoE UdBGmP+r1fq1wo0RjNP2lO6ogE4K6rHBDiI
vju6pjOUnrAG6iB96EnHJ4kD7IE7r30OakOFs9+qdh7rDlCwwxaMExEHgtYAbuIlbIAmAB5Ut/8C
8GZ/YN7oRHQ5SEh0LQgOdIGwQLQcBNC0H+oCn8EKzzDrJScEUSH0
6ZMvw4HBoOvvMK35/W0mMYgW
gGYBHwgCz2Sd6+XtaXQdBHR0EHd1XtwxIjgCt4LH1/+xiK5X1diRy3v+QlI RvzLZi/3pI8dQDAcm
3npIw20naEzhVhhfT1AJ+m9T0WfrheAS/yCKA0M8fHQe93Qa4vylnPsWPFx1HBIKaw+IAf8HgP9g
u1R824sGIJNdwzx79pvKbPmLvYvTRooCQir2se6lAAx04jgJDXXr69Ul9AZto01BUn+L0Ukd
3ErU
aA7nZHXSF847+8DgRuvLP8nrJ26hQG35sJsI6xk6B4vx9pQyddt0NwUBSkd/1Rx3ndnR9URUG8Pp
Ckk8JKVdF22SUAsPSYAh+wn+RKk3Pm9TQv83x4Ypih0BBygz0XdAaEcU91u4C9l7pDmJUnhOPCBy
kaM3Nn49dD08KwM8YzU8fzOALaBxPIALQSlksm7REAIORls8130h2qd+xgQGDQZGB5Z490QKdLIM
X4AkBlhjkIOkaQqgCkGSAZmooAjbaaKHW6RaUBghajC4YxuuXlCA4wU4ROoQvlgEC1ChvpV9vPOl
4mmkgG6l/opMDbxfiAr+D3AB6f73X3PB4QTB7gQLzheISgGKSAEYAj5blmUPAgZeGQKKQAwGt98V
4D+KRAUMQgO9GCKxFc546wUMLMVkA4FXLnANgkWD6Hi5iK/CBChg7AEqFRf+ffBhPbIAC3FyJlBX
X+itNgJc6Fw5KZMhFsCZnzWLRkJK8P++/gOKhAUriEQ183W7jVVBemeqC45Wl445uLgHBs5Latcw
FJAB
9BZaaNR9CTmXAxgR5nZP3g0EfQ0NQwQKQwzrW4vW+DX4iAxOZUudTKGIudhyDR2oIDaGEF17
BHKe4G1XnwG78ClEVq/ndCqIn22DdqNzBN09CAL6PZe6NQRCdR88AxMEpVaJhnMM4RN/papCOWq0
wVx3N/rei5y3tMCNn7TQZWPlI OabUAW7oWeMcQ9SD9goUATFqUBmuBrs6LZ4bUyHX9OsFFZfb6cN
VS0Mqij/t1Vou1aqsaAW1ZUbwIHHEbAHGohskBaaje0mRxxoiBXXGEOzBsmg8hZ8ti2 sRBAzT18
n
G/eAjiKaWU/t/G26KOV4i7jbaPApNVWzA5KxWdOit73NJFcF8riYHUGz77 1qGlRXCs lGr/tBVRSA
jCJSXF9wQUy5UtxffAW5UWPRuYQjVgU0UeYm63ZGaPirV1YYUA0FHOBhtGkzCUjI91IVK+TzDnSD
EfjAw1NIRbnhon2fGgGvAX4IRQcPjArCaCR3wIob00D4j4mdD//x1LKxykaaRn0GibVaCTl4G94J
+3OhDW74fUT4ib1E+kLsO3PAH 15ZDEELg3yS3QpL9U3DjbVP9KjE t6vdXnVzi7G/AT9FuPfgAi1t
BZ8jYSNor QcMEwxAd7vBSfUVUA/0IogYTj/8ZidXvgrOWJEtJzidJ4kj1Or8cOv91jldjsQXbDcJ
kOhY6xiiEpTAJjwhckHDChkxuAA0lDhHsX5yVtiCFucIUSkOJsIL2MUQOD2ZOiRRbqG9v6sF7Acy
RSFipsfeLnzqPWQUnEYBJ1X0CNrBgNJ+JRONgsjWJA5YMngJV4MUM0kCCnQKAA3ApVgDw9OX/xxA
c9IUVJaDyP/rrCIVpfeOwluLC9XgCZl2PzBFGzmkYlfGBzAfIlrVgJr2oMts/EI/wDvwVyJj6keW
kW0ICFoMURAP36D7zY5IigY8DXQMjgh1dAQ8CeZqiRITMOtCJisRI8wq/jQlmg5uYkYyPjw6kA0K
2gb1ZioCBBc9DzhADfQliTiEDf/wEHwi2s4mSc6IED6B+Y2N/V8xcr7rAU6ApBIAXcy5UAfCFVRB
AP+YobXo035KqQ8FMVe7DiQ4MTJHDbt7lTg6dWEe8CPFZKZGD9wRQOyKnrlG0soBRnTST4mmc01Y
FsG5YV1CH8vCHwpCO9d86nUMAihCuvbXdR0L4zc+CnXxBQwqXWqj6AkIMA2u6wsaYmOuIAscBwY1
DRzRFlRWhUM0UA8j6sZOjQ
rhDTbSDQCOkjVj/YVquQ11hPNHBIvCigrrH6Qo1C08Bxc4PHUU/Kxt
fBI+H4ijFfGAIgAMgYEg20Y+DGLjBqzwdDJ7ECSEaSjQUREsBjFrGHMVRMSv6QiCRL9A6zNuqcZK
UrKKlCCpvtFb+foJdRNBBzl/EoPSjQSAJvy/l9REQtAeMH3pgDktdRlpHdnUo/pUWrR/toAGQXqb
SL286NQsclM5QlAWMF3cK
qC632z kW4VWG0NdMSf8s+aSQ4wQLhvqPQFmJ92KjQWT0BWOeUkHMQBc
gB8S5WCMQFOW9P0jclWHar/lYrKuB9iD++T8LYuCyFLnp9ZTUUBfxw8WkgEEMHX4w3lhzQJvgL54
WTvGWVqXPd1sqxPPSIzjZr8F63bfIE4xiLxofARXN9ts883ENHwHPSt+LysmeHm2kTxsWjwrwUWT
8I8xPrvVGm DNt4EOZDZUUzRurU5zB7+NNvoAkuc7RDExTDyyz5w91QAszSU0ILGR7lnhtQCGj6oi
CwYeW149NIxqi6pl4+PQ6w3WG5oNQslob5n75/h17AjsR1Ho3QZCEevuO8IBAIMHLEQRDwGP05uh
 cpDPBRMrBn7RicgQZ35GAknedUXeoCoFaCwq3xEO2PxqmXwfd30Y2iRga9Y+iBM
OHvdZ4IzohK/8
qsaUOIdRQpEk/tOFh0/puOR2UIPYKiPfZ0PA3K6wKmioUqAtTJpjF1z/mDUkF9CCBumf1gGxgLMz
V9keB2NIyUph8PdBjNiHBxAQXtY4+LbIRN9XH9Em2J msFZJK/LPnI368SHqCABTcKNFkAXvscgHf
7OnS3FefOPC8Ao96fec+HIi+uVScW1DgdCtqGS1yBNkO3OGyuVSYqt6p+F39sVa47Qcg9LCdS0TD
HqMA7/R1GLpyAI7KyodVGxaAK0j/7zFe0l0nWw+U9hQDKiFwWw0MS1bsPUWQkwPpUdAM7OYC+Tzs
/Oz8BTRtHmpfu4RAV9XsXShMjNacOnsIc8nIk/DwdCTsDMT/JUvu7HREixuF23XHIdSOQwvfHbpK
g+jjQN2+qkJIdDgCLkjbBAWLdGb4af5yox/Qhw/T6yV+Y3NDGLLvXSbr12jsBtAm1oBF/ jWxCAB0
WI2nZMAAyDecL/feuXh8Dy93Yq+ApVA3Ti2juyRgj1kVXeIHno7nQDPXj2iRdGD3N+fxQYiMBfyd
QD33cxEANl98GCSuF1egHtWmjhmsqYltR4FZIKjElhMkDCAJAe8sM1hZkbt09oLbdkIhinn7Edhc
dBUEbPG9xS8YxoQFIlwFBU+zzwFDr1w4iwg byGCRKw0Af1AymMDNaauWwUhcv2uQVrniQeIrktmr
DjFWwpchGFbNgBubyA+GlQE7Y2PkJp8ZLDcCMcBAD4CPjl8RAA50mt4f4HeqRjFGZlhCYIdJqsEV
jhddqvM0V1WJ83XOEr7nUjaLNdZN1s2CTUbArVObs2UQpexpGtPxkQHr+HRaAsDCecKGvlNRHY34
ypJJmu7rKKFT+Ajk5WxYF6Fd1jldgssm Vc+aW NqEXSSUlWRnv5qF5irlMLsXBkORCLbNvajzq06o
V6oNmZAAAC869qVXmCN7QDicBS32OzNIRyEkNqcUPLM9zQ+oiCWpWSDHhnQgGA0wGCODEHmsJTEC
qA8gyCDAf ERwCMF1DxY 7dzb71yhj12N4WVf1NVA8wMOKTf0QK7ZqRA1DgAv6XlZb/KjALVEL17iC
gWItchAOFyJRoVXdZjonU2YWSg0DJWRMH8PwsqCTaOAnaiAnSNYFYwBdftyivwCw0l+Lz/fxuHMR
PQ0PSwAsuOBahHra/LecIzxZIQVzB2iA69xdE96sXDiuUHMLWIS7CzlodCw
lIBpnV/J5PHMmJCcy
NXCJkfwmJdwlaXDcADcbVHMGYDV79th1BGfeaGg7LAnQGZvMkR4u1zZ8UIH6wgp/UiYn45zwhH0p
DINBcioLMj7J2ZMechcSFAoPg6gaumYoP8ZH6UMcHkLe 3FmKAjho2Cs8chO33XZKc2VC0DDrQT8H
A3t4JTdIaJj39zYEOG
M7u2zrQVk/JZRY8lKc
wGyQMxgDNAQCdqncaEhHV0tQAyUiDDsDGJW7RcC+
JCVYETCkahnVBQP5/TArOCs4zSUcfYD8/gSozkRgeLlNDl+fVMIFsv8l+HslAEVhhgCyACeKIiwD
iBKmaZrmUACEgHx4dJqmaZpwbGhkYFxpmqZpWFRQTEid+5mmREAACBUHA/iapmmWFOzk3NTMaZqm
acS8tKykpmmappyUjIR8mqZpmnRsZFxUTGmapmlEODAoIKagYaYYAASaZXe6EBMIA/gT8OhpmqZp
4NzY0MimaZqmwLy4sKzYpmmapKCUjIQTXzRNZ7aXEwNsZFiapjvbUBOrQDs4MCh/kKZpIBgMDBvR
QUJBeXbZbQBFA76++UEAAUHy/+4qgQRPXvtPQfVIjGD5QA37////FSkoMmExMy4mMyAsYSIgLy8u
NWEjJGEzNC9hKAIFYP9/BQ4SYSwuJSRvTExLZUEA+yfk7REEEw1AQqFBTkBKQEbM696TZmFRMSYs
AzHdkG/2BRdD9zxF7GwW7MEzHgxRB/a37A0GAE9FQEEAm4
RPRRQRGXGoUcQj3WQjyqEncGGdXNlg
/
1snAXNI2WCT3DH8XyeiEUR28gD+/4+l4XUnYE1IQ
0gE7T90JpRCgmMC+rI0N7ciVmlnTL5e6/+7
/98ArTgzC4ADehM4quFOvgBGCuwfkCrZB8BB//3//4zH7wG4y6Noe9/++9 VKdlcSBiStT+sjqLH8
zBnn////Duw+7wvaYBqRk8pn2rKW51JJ8CujUI5mNWDl/////+pBeFzPqdQLrcyWB2tSrRJQQplE
iL1EqXm2yNO+I6L0/v//P0D3YW9X1C/bjEwPeZy gNA4hXbCaKiQzLyQt//+FANglLS22uv4+zmNk
MmNGZG95a+vu9jlvZCK0hlY3OG8tZjtV//v/fyIoNSRBOeUrlhf2 hqmaMWFlr49W/IDuTj20u/3/
/2uHxgZSB3HpQNQHvJnZwSjutgXK8Bod/5Yj/////x3I Y1DRKtIw2bzPAjjnYEn1CCNkX7cB8gGB
EBsfZ////8/rhveoHFFulxJVBUPAp+CZibqSpqeMoGCXRnb//1/+gsZMlLWsVbe+GwREqK LoueKu
vZhDxssNa8wD///D/3i7vsC3MMZjINx
OLE15pLwFq//l6I6fCiEK/5////q3Mf3+/4c/2mm7ZuCr
xHGulURcyUV4kZWYpI/8///Ymqe5PeNeJBfthQVjaLXWvmsC5mLVeOHS8////72CGBok041Nzjy1
rr6QHMXEDj/pLqGnbb9VAkD/////4uBQSQ/DPxK2dLN7/PqTlmvQkseqRk1QV0RIT1VFSv////9R
j3WcvlZHS05UQUBDQ kJFQ0BEUC/EmkRER0Y2bkAkNf////8fmre3oAgvNSw1BkMCLi9JIk8lvqz+
oBI1IAwUzC1lzf+//f/ArX1EdhIXFithGHKB9xmxzPz5vHtymrLqh8R0t////79IQEd2uD4aOXIP
wWRByocSaoYRzMV8eW6W/hG3/9b/ygQ9vjFFvlTFUUZ6gsgELU7P/4G5egb///+YG5q8vz2Uz MR5
eREp
01BjabrQbNlQbmU4/3/7/8vNRB22np6/wbgdNbpuNU6HxURjHcndRHhGmv////8/OjbKfGFo
KyQrOUK+lsK
BQiMlRiGs8j7KDCVO7okQDP////8pGVBgE4wv+5jMfEw1woVZY7eo+/6bK0MSK0Ip
/4FaXRL/t/+5vuz6nP64KU6Oyj w9yBwl/0FLqlD/3+D/HDGupD66P2XKFKUxwqM+zM1MebrL1VTg
////sba3N7pxUL4EMUMleEQ9ncxhEhARI3oq9x66////39spGFkSURdQnplCIDZZPudOwY9hRJZc
oMgeRSh5////b/iBUy0n8TYpdDcMR77ynlrE
qXjszAT5SVmFVVbp/7f4rVytKx0XW2VJPk68Jima
jbBpFyO//f9/ew1E1U7crezgWjoBrVE9q
AcYEvJC7UHsVUn/////5T 1WSz
5En+flPxCcQS 16YJif
9odKMTdEykenLYIaatlf+P//UbhlWk7NlhX3fJhxXdZCPC1e5cyXtqJNerf/////7uW4GOKdTPgd
6dVB18p0eZOxw7CXa3miEccueSCUTXvQ////PFErUBh0gy/KvAQ
VhgRRBcJ
GEZgrQMEsjOz///+/
TUxbfcAnkQElmD/yeiHEgTVUK769FSWMJT0sGSlMv8H//5fZLR6ivoS/HxrChDWIgqrMqkvKrcKt
bf//W/sGrTdoB4/RWXVR09ZaviBxSpF6ksgUuQz+/5f+hkAWyr6uh6hzgalQcRZNFkkUGMIMtb7C
JI7f4DfNCva9+n6sxQQORWHO/2 /8/8y9JUnKRYB6A001DXKTqD9QyjS5eEXXNUQD/////5c/qi8O
PbJCdGC1xJM9TFZqxKyCvjWwRXo1kEU3YARa/////9eLGEwx0mwKP0lNTkcSl//4F/ErGEN6Rj3Y
R3+5LvW2/f///4E9VywmjrnIRdgCwrpRLO UcGvQqrdG1QZOofpmOPP+//S8zEMLBQk7Mwk/pZgD2
nCy6PCrKBnsMD33fWPj/iSt6OekRcnJu1tCBDBgBzEK2ilX/////N3gW1V9NeHE/UVEurC6aw
XZN
qLZwepc8RlfPfdkC8vT//7/wsz7tPIafPc++R9sy9pY8RXcycrcYKhRpWyv/3/7/Sf9UV113t5Wy
ArXMVXEtIVZcPE7KUMKARcgVxP+t//+ZfKyrczR+
LUCVWlJMGEgrJ29ZqN9JyXYCXej////Ch0Z6
sj1n4Gz59TGauWCFbYKwLif3OFN8GBj4Bf5fD7HEfg
O0ZRLKHEkX9cpxF63P3/j/F0WMvjJNSVNZ
yrnKxL49qudfOnbKD//////LBbhFYjLASloa0exARTLgQKiT7Lqcd073W2yGScX7RP////8JR00n
L97qNX1IxPOpnX8h7+KTnYUD
YU7DzreCHiZWEf////8mUssYI
IyqPNgqnjkgGxh4V8m9PxWq7Eeg
vj4YCMqLg
P////+gQsx9UXp/PFLKP0UBjrFfPyB4eEnIPcSdeacOD4Nyxv////95nTJ0vUagr/J+
S0c975iqURJGQ4OqUp5ZxR5JRKtqFzf+/6XhHcS3KhKqnjVkZ0ahygegLJmzdf9G//8eCXkXLU8p
H9ZfdXEjP2Gpu3ZynHJLYtH/C///UE30miwTzfjGAU1HNEWVmRnsLKjKiTBAVC//////NPfsXJ7Z
cTVPA0vCuwKrXx9GqEmuXoEBqrn/dRbHSAL+xv9LjTFOaklYrkvRUx+g67zIPLEpS9K//TeFNK3W
3Ufy7H5WF08Er8PZDLS/wf/SUfVg8yxOvcTV4sp7Yi34MkD//7cLzhZG5bi4TZmaPVlPyghPmEXC
3bw5XP////9OqlNuMnxS/7
8xbGEpJVDGvSyzWFjFGr2NjTS9HIOnD/8v9f8zUFJQd7iR8ciCamMq
2R8e+/CUw8ezSHnwv8D/2TUJ/5V0BDIxtjCJfZEWFzz5zK3///+/hN5rVcB5Lj9a
mUp6z2YrJX62
sAUeMkvkSqzgcdWd9P///whDRaKC9+jKGmMlZWcUSj1lp7Hwn
3GZz0sp2Xv//8u/QWG+dp6+9s5G
cq zWwoq+eGkYP356nD1hOv//hf8N+oW67LH/DZn/Unn/9oEvnfTWLNgsuBs9Vf9L/P9wYL51sTcg
umDkNEPKn0uXPYASXO2ANzL/v8H/BBjlZ5kWia+M3JFOtLF6tMKpQhApXXnAeKn0/7/go/ds/Z38
6cK/AXpHST9C////l013+ZzjxWW+BULCuOFPSy3+nVURPBEferE/L/8b/P+xkiVeP3b6P2QYS9Jd
VOpWrrs+CjxABwS/0f//eq89mg
LtRimFSGwcn50eX8N8tzBQgZVA/4X//018fg2Gzj5RKdEeQKJ9
L70p2sScIatur8J4/9b//201S9vNXZPuRyuvGEmNRU2J
SUB0Rb0m0afW+v//W7c/YLpUEHM+21G9
weVEvC8HX9tsBAF57d/4t66XlnDRgEwpbsmTwi83VyLO//8v9M4pU103SfRJcWO62MXscfdpVFHA
g7FjU/////9cLPcTFwTelRdzhKnZKMKQAUAYr2Z8+xyBvxWeEocEhf////9CHG/WioQuhyeGNYk2
iCCKpDP4VosziiSNHYwM
jyyWbf/////WKI4ikZBukzJ2iu8o25 KVlJdm lhaZHPKdd5gvXpslmsAL
//+dDpyMM5o0ap9engICoTSgSRyWNd3//79epWqkfqcXTqaq++8qqVaobqsGqn6tXppErP///wsl
E66xL8kcsPe12yySdLRvt7Y337m42ef3Kv/SX+i7Uro1ygWWe79tegSB/kdPEb9L////
rm5LXESQ
WcE5woMATzJYVUA0bqcsRDqIBRHb/7/BT 2Pt2OyANOaBWUFJSTGiioHgJySFuv/2tCkB56mPloYT
JCYoNAoybrf//+0zgbAHL5JKs7I3kSgiJAwm2+cRMy5tvaH/v/3/Nnc3frwyOw34DKnGwIixTwls
gW0hVxuRxqlVEv//f+td5Ih+pnEZgWwstLw0SAEfwIVggiJG9r9uMf////+6K58cnQDIR44BHqo7
mAHNoOJ4VgPIAFGBhjeGPFZoRf5G//9MX0pNDcpcRQtevN7CJ0lBT/mhXjm6hv+/8bcqMZLKbO2q
WTdV2gwrDkopu1o8Y3f/En/jHqGq9mor8k
OjB3SUfZf0WoUW2/8G/xFJcu2PNP4 pcCJcMT4E6Yis
7ADMW/z/9m5NjhHid11TQ w73vhQUyC9ZyOVh/3+JhWAMw/InniuwP1kzXPn+8qi3If/////s41rM
Bk4mWXq9R49cOkkzS5UGyEoGd/rxmvc/yCBdJP//L/1Rcq0GFElJDPZhFF1 lXYZNEYJxrdDsoGRR
5/3////lPkgWm4HE8bGqxC4UL5mXmBn6aTRW5YPhVsHD25t/gf8vS1G2RhrKunUCJT6QnxERhlML
Akn/hQv9EWyt8y7B1EU0OBRtfK09oHFGvND//0QSKVFYv9zsYJxeef3R33Hz9GX7QPEtfYMLi0uA
FVS7W4MHiP///ws2EsuZy7o9sLf+AILKu8qQgKFRJ0iAqEPgwtv////ghE3/suseGoAc5PSdvhil
wj9NQTSzhgdNA5SaEl/6/1PsdyGnI
VOCCj5Cb3usjoISCzgUKvT/qw8xhPe8XNEGergkZ/8X+lv4
H45JQgeC7NEVYDc6McjiNET/////lXkHSWKL1JupaokKgu5r7vZTBvPIH/QOqnj+5gaHTrf//
///
eo4/RwqegKJCEpqR2Sq+A47IF0U188qKAXQBMqCB9Bjf2ur/gybkiSqVhCxQYT88ygzAWvsV////
/3pKATV6gz0I2R HROYm+H+j5U5w22hFVGIR6yoa2kYdy//83+Ob/7LV4xzxnU3ZRZj3K
Xix54nBH
KH2AJvxbfK
sqDE8Xi0fvUhhG8tgXFP///y+UBrZ6FudzRgkWCHqANVBy4vQsSkqLAoM2eC28if+/
8RcfK4MfRczz6uq+Tx4LYQqsCQbH/3+rf7rh+pFDeb+5+Gbq1/zHKlA7OXU7EDmh////rWkQ9VVG
GAu1CKzrLbE0YLipwKTnol6IHAf//79VXDVDtpQE9bj2LMjI3ob+DXQ0kMJnQePfaKMrpFkiHLTV
QKpHkIr/v/1/Nl0MNK8Ralxwtwo9rYRXtpNwh4FFCDS1O5r/L9Dir1ute2kczC9FX4RhqPQLQvpv
///Neg26mK81HHq831kjkmgfScf6Olk0rjd Wf6MStwsf+u+EbCBZrXy+F/q3+moZLO7Qnx5 ZXQ6h
9H5/RQ//////NJptO8NpEkrDhUeaEngo ovMhegFyTSq5NANGIHox5jT/xv//33hfX6zDV6wQFujZ
SjyZ5ffbudpNZ4vl9Jv//7/0nJXbyg1UyA2gz4tlDuWZvV72O/fQmbklWYL+/6X/m189kWdcnfAe
kNgWiNDnJ2UiZZ2/mF4IX9Tg/98FkTUMFs69Q73qd3KIHsi9Zvrf4C+uyeB2G3Vf+SvMoQB
/ZRqS
L////xcEPaaPXtSdUSFzc51JArGXegJ
KZFXmwjxEGD7b/0L/RqzztQvyxcMpeE0SWh
HJP5Z20M3/
////LoUjxUZwLYCnQxfAww58zP1H/lcfpEJjLCTKkjJsFDG/xY3+0aGaeDQIIDVJKm24HsNZ/6DU
29sdt72JP09E0lP12xv9/9+mt0JbWEmDHao/4poUoxWR3B WJFUdC/3/rbMgBF6zbikl6Tltili/M
n0GJ//Tf6v/y0CE93ikmIQlDCDZNPw0h5AKC////dy5xegxRninK8aH/ZwZJ+lQ9qWBNXRncQtMU
9Rz/xv9b0sDoYfuOOYiIcvc1R0IXwUEmrWvp/xf+OLq+HDttVEjTXV0YORcXJx5VHcMaed/6/39D
uRYHeoefHzlqgtdFP0QztTUF/D5+DJb/L/T/ZEgX3BfdlRL2lK7q6 lHcPL03W1RUGRdG/////5M2
VHDN1uEN76rqEiYYMf0jzLZViABFF3f8NUgREG5V1f8b/ERZbINZp6nbMbAlJ80mhdEW4Tco8L+/
7dG8/FHNF+mDxq3LQL/w///FnZ8RiwCphMlAM6tEMlp5KYYvS0ZaaovJFP+3///iFEtZDsyPIq9x
hxOBWNBlH7wEzTFN5gsnLa6IX+D//59XUg40i09CqSTdOwfwGCmUzBEUY0rx9P4v9P9BE+z0Y035
hDjyq3bbcoF5QjVgAcF9Qr/9/7dDuFdCgssJvjHo3jvtTfdGh4ohQKPoV1/ g2/8cTanQCxITIvcU
jkTivWE4rIC9rt/oL/SAVT8LWbkK9L5Tw3tEqX2vL/X/
W/9zPUu+nP56o4BxqlvLX1tSwf+/1P+g
6R63mNhaiFo2S7 a+uGFYAEKLdclPB8n//7/EoWIdhU6+u000+L0X0NmxLSUZgvIRwv4F//8v9ZpV
QUJ6QGIEJoYBUs0ePzrqjK5HSb+d+/X/C//ZTTcVc1HJLE yqKfwW6uRBS01gn3tL////L7fZqhKy
5OPXD6waxE0E2FMYPA
Wp
jPzFuE
/ZpEf/Ut/6RDk2U5r59K1liEG10kLkTmDV1v+t/ndtsInZOUPA
VKpP0cqlqG+hTvf+Cxf4mUvLPfHUJr5nTUzJzD66t/3//6VSQzVoCjVWQ0q2l0rMcrZCh6ppZLk+
Kv8v9EuInnKfqlxDtpJinryD+o+8Yr/C///bSp5KVk6f9GK2Sp/PnvkQyyrXzNmvQ
nz//63/gJwv
/rEYagxpK0WSr8pJkqFFrUKcwej6gX+D//9KsfNCJ8NzH0DjbcTobkx6e2LA1xkBYrX9////T0dk
nyPoSVmZCsqXGhmig5pXvHnGCzS3H4iDOzSZ////L3R2AVF5LWxu8O8W+1HKgEJtmOQ
swG5DfoCj
Qq3j////yFMyDp6ZowOhKw
EGHvpcQA9V+xGh5GronjM
Mkv//36pTVWRXEHGztMtVUMlVSQA8yQcu
0zOz/41 +68wIvIJrhLdaF0OCMmHHSSIDWv7 /X+qtp+hAgFvCUrnh8ZDE+ngcMKLenjee1/ y/1A2e
D2q/VQvMNRBClstF3JH4v8UbnUvJRY6KM7RGHJ4JgHWX////30FOUfgDnsRs9
/d5J0fO615R/DBq
ptu9GPr5UvnB/7/U//yMkS4JM0IrORjVEDQC8ZdGzrkRSlJuIHzr//8ZY8FqFc5VR8j1AS9TzSoW
VAcaEpV6RKP61v9v8VwAEuivRElGdrSi+DagdIbiVhv/b5Qrp+BBXCiBvMG2Fr8CuUT+L/3/gt9n
TifgQ1qAwcSPzYk+1rkY2aFygIIdf//2/60ywKDE7DTeq8C4REtXJERXuSw8Ten/////A1ZGv+hR
 ZELOn59Hsb58RVHtNREHOhk0PYIQF
//hIxf/jd
76tzRKSxgZ6x2znu1bEQn2HZ573+IX+EQjGapO
Cl8Qvnlm6ZG2mVo3+lv/gUIfGPkJ7kpPtXzH0St9m8Yu+v///5KWzEBcUVARbkURdbbPryxZkh9
F
TsTj6mpxGroP/xf+Nzl6YFPOrMY8Ud+kVxFtVzQ4ylEWwfS3+O3WHGvDdBEETtFYniEkJ9+n/1/i
bywnYadLNhkZG8Bb4u0RWkBZ/
YftW/z//1CJFExlnzjxXFQ3chb5K2nLPCgavxuDX/gFFvqNeYlb
emNDK6kbgAan////l1VhaF+QKYzlULQZe5CDDv8j1FFiH6sbxEkykP1f+v+WQJCrjSwy9RFgqwS9
drqunK
9O/o5hRVD/rf5LZXBqgOR9BifAUZ7s4jc9pQnY+/9f+GoHzMMG8jH6 nrP7RxIJa31HRQGe
QorJPo3+/38svElziCe2mJoL9RorbLSTgxwDTt50/1/g/0g7gKr/149HXITVbCo19w3WeoVhyrL8
Jf/////b2OXpl5B3iTlRkqlKt5qwnO7M1FflcVxjTxSpS8rcQf//wv9sYFzrkU1u8QQGDl2p/08B
JzS64wqrM7FULf9fWOiztwTq/Rg1dszMBNTC94rqRKZ/ib/198giCcZFmxOm/zEQQYCrKQw5////
/zSo0SdroZ1K6ySmse5NYdV+bw5drPe01KS6UWEQHcuU//9v/7haCjfADqc0EwW
oRXFW1O6astEN
rjyxc7Y8ra3E/1/ihofC4RrgUJq8t8dI+qAGBGhG///fugWtnqip+fTwJh5IQ619cKp8kbcn56yt
ql/i/6UxsUJzDim4X6ruONnNj
TUdai5SX+D/NzxzgaTJBKXDMf/VWjqcv8v/v8D/UD1 sl52XWU0h
nEdeq1ft+CBEGWFJHKWh////WC9ueapnPDEYYzSk7hU3WOBUMC
mNQUFrYS//v9R/SL/ap2nNUUCl
ICUHKC0kWEG/HxIkNf///0ZGLigu8rft/E4WMyhGWwIzZEoupB73AGZ/qb/UBhW4KgIuNEwtz5y3
gPczVwTw//8vViQsMRFoKUwJ8H6aL3AxB3ckSNIv9S/tLiJjv6efmt9JJDIyVWCXuP3/MiQJIC8l
Dn/6hD5FJC8iIP4uvwmA/1ZArSU0LTkPICyW/7/AfyUlM4KPQ6cEiQDqLZcnnBUpRyU9oz/W////
G4i/LLIxOA0uXQ0oIzMgMzhzxG6cIdgAuCBOLvT//zMSSS9MwfYmEw4jKzBVBDnDkV+8BSTrS/wF
Gi55KFcL2FwCFyA txN/g/39KhvckbQBODjFbCiQ4T+aYHa5Odec1+Ld/iVFJsTYyMTMxJ7o9bYrz
dLFP/+5339BRUnXzC3hFVkhAgwlTTEMySbe/SP8Z9dI
4OC4NQEMiT7PlGGVDUf8v/QbHQSeAj4/N
WkVyRhl2Grc RTXul/v// aVF GEc9kWkdCLW4YVmHtV0El/V/xTkodvHCr/8U5BCdj0b83IK pFYnoh
byX9/y8tAyD2pSpNCgFXgUHBILpFzXFCj8yJA3lGFGG+Iahj/7dtEW3MBYG+ vhbCjL6qUdEAy3vj
/41HMkYGQ Jo0Rspfwq+9TzOs+UEr3Q7YEVCBDDKuKg6lLsEHMqVwiHMzTOEd2Le6ST3CjjU1yIQv
iMJC9oQMNGEAHEwL/Ld/woBDwLxBspXCkED MVW7CvPlOSvFG7stDA5Sktqgii/7S/w30Q8KDRchG
woZFwgg2sECOqA2X2LrvFh/Itvg1qcspbc1ANsHCb/W2wX5AVspGyx5FVKk2+P2/DoFRx4Vou
cGq
qUCxO0TIaZi33xrl/0wjSIE1BMonzMV133aFcRjrshEfSb7XJQvUy///1k5JHZ3IuDhGTvZGBhEG
+BYJs+8UKTfbvzM3RshCwoJFqpkQLSCoAkQF5qr5vgC5kFujAxMlMdghaYakNec911xgm/DFMVf9
ix+DDDZIm6kHt0mq9CMAdUEKBBMPnI9R/xf2BQ0NQQAFFwARCANBFBK5yQdrGgoWEnMeMW2D1WpN
7k4ADQZcry1o8IcigaxgLLbVD0goEAxB52q1tsACzr87DahK+C8wKC81JwDzFEVYRUSBgMAajRYI
COQBADAKACRRBb9pJiCoHAFGaW5kQ0QBoPJsb3NlG0TM3hXUU2l6ZRfvf/tMTBFBDk1hcFZpZXdP
Zg9ub2FvDlVubRAuA3JzIm53wy9LRW52EG9udquKjl1WImFiGDmIu B1EDHZl2u6RipgOfVRpbUYq
4qy1VxoLUUOi27r3sQt7cF5nLUzDbl8gfkxpYnJOeUEh9kxQtFBjKEvGRDm2/WJhbEFsBmNYTGG3
PexU0ypNdQN4KBubtVtsF3JjD36wdBAH++daVh1GQ29wecVEZdqHN2sGgxclSGHnCyDdwp1FU2PZ
djv5bGVuVN9wUC9oDWELCsNXK1hEHbO3RUTxb8qRtlDEyXB5TZFsW3ZngiJNE0V4aUJB8WLdaHFk
H/G9WcAm/y+ZjfeGDbsF ZXChNkI34sLDsDNuWpxlSXsRcaLL+xdsIPxechhUb 5MVhpmiuEypDrwl
exNiEQ0IY2tDhW9PRHIB42RlQ2in3F1EbDRNb0J5dCISFC
cinJ65r7UtCmOYNipSoLK9J+FUR1Bv
aSgZSHvBZu1wRiZcvRMZhEOYMOg6bkVMuKwwaQlpnBakIiYEOk0YM9c4Q3UYfRk6JDlhb2ulRGUs
lYQgxZVotcce45vAZxtLZXkMT3Dr3KNrMQtFag6AV
lu9ABp2dWUPi8zcpYQRKXVtMAxPs80mtz9k
wvhtoKJhbodzZTCKNxdrjHIQ9gdpc2S99lwJehnyzhAUoniuW1AIIjk3oSszKmEqIQJKD2azVM0g
AaFVXA8WsN9OQnVmZkEPC0xvd/YZtiN3dklylCN3CoWbcVr0zAxNgsIAqG1Ztk3Xt9hiQP8EAhML
ZVmWZT QXEhADq2VZlg8JFHM5v/+EvDxQRUwBA+AADwELA Qeue9JsE3IqgD
IEEAOCbGexkDULAjME
mVvSzQcM0B40e
9kb2BAHBgDAeQhAgFtkeAIYBUa4wnYrZHgBHi4v2JOgmKRw kOs2f7uwBCMgC2Au
ZGF0YZgj7kK6wfsiJ3ZAvc1gG4Uu5QkAw8AGfL8pezQnQBuwew2UAABKQTwJAAAA/wAAAAAAYL4A
kFAAjb4AgP// V4PN/+sQkJCQkJCQigZGiAdHAdt1B4seg+78Edty7bgBAAAAAdt1B4seg+78EdsR
wAHbc+91
CYseg+78Ed tz5DHJg+gDcg3B4AiKBkaD8P90dInFAdt1B4seg+78EdsRyQHbdQeLHoPu
/BHbEcl1IEE
B23UHix6D7vwR2xHJAdtz73UJix6D7vwR23Pkg8ECgf0A8///g9EBjRQvg/38dg+K
AkKIB0dJdffpY////5CLAoPCBIkHg8cEg+kEd/EBz+lM////Xon3uQEBAACK
B0cs6DwBd/eAPwF1
8osHil8E
Z sHoCMHAEIbEKfiA6+gB8IkHg8cFidji2Y2+AMAAAIsHCcB0RYtfBI2EMBTlAAAB81CD
xwj/lozlAACVigdHCMB03In5eQcPtwdHUEe5V0jyrlX/lpDlAAAJwHQHiQODwwTr2P+WlOUAAGHp
I0T//wAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAMAAAAgAACADgAAAJAAAIAA
AAAAAAAAAAAAAAAAAAIAAQAAAEAAAIACAAAAaAAAgAAAAAAAAAAAAAAAAAAAAQAJBAAAWAAAANjw
AADoAgAAAAAAAAAAAAA
AAAAAA AAAAAAAAAAAAAEACQQAAIAAAADE 8wAAKAEAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAQAAANAAAICoAACAAAAAAAAAAAAAAAAAAAABAAkEAADAAAAA8PQAACIAAAAAAAAA
AAAAAAEAMADgwAAAKAAAACAAAABAAAAAAQAEAAAAAACAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AIAAAIAAAACAgACAAAAAgACAAICA AADAwMAAgICAAAAA/wAA/wAAAP//AP8AAAD/AP8A//8AAP//
/wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAIiIiIiIiIiIiIiIiIiAAACP///////////// ///gAAAh///////////////9
4AA
AI9//////////////3+AAACP9/////////////f/gAAAj/9///////////9//4AAAI//9///////
///3//+AAACP//9/////////f///gAAAj///9///////9////4AAAI///3d3d3d3d3d///+AAACP
//d/f39/f39/d///gAAAj/939/f39/f39/d//4AAAI/3f39/f39/f39/d/+AAACHd/f39/f39/f3
9/d3gAAAj39/f39/f39/f39/f4AAAI////////////////8AAAAI///////////////wAAAAAI//
////////////AAAAAAAI////////////8AA AAAAAAI// /////////wAAAAAAAAAI//////////AA
AAAAAAAAAI////////8AAAAAAAAAAAAI///////wAAAAAAAAAAAAAI//////AAAAAAAAAAAAAAAI
iIiI iAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AP///////////////8AAAAPAAAADwAAAA8AAAAPAAAADwAAAA8AAAAPAAAADwAAAA8AAAAPAAAAD
wAAAA8AAAAPAAAADwAAAA8AAAAPAAAAH4AAAD/AAAB/4AAA//AAAf/4AAP//AAH//4AD///AB///
4A//////////////////yMMAACgAAAAQAAAAIAAAAAEABAAAAAAAwAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAACAAACAAAAAgIAAgAAAAIAAgACAgAAAwMDAAICAgAAAAP8AAP8AAAD//wD/AAAA/wD/
AP//
AAD///8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAI///////wAAiP/////4AACPj////48A
AI/4///4/wAAj4+IiI+PAACI9/f39/gAAI9/f39/fwAACPf39/fwAAAAj39/fwAAAAAI9/fwAAAA
AACIiIAAAAAAAAAAAAAAAAAAAAAAAAD//wAA//8AAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMAB
AADAAQAA4AMAAPAHAAD4DwAA/B8AAP//AAD//w AA8MQAAAAAAQACACAgEAABAAQA6AIAAAEAEBAQ
AAEABAAoAQAAAgAAAAAAAAAAAAAAAAAAALz1AACM9QAAAAAAAAAAAAAAAAAA
yfUAAJz1AAAAAAAA
AAAAAAAAAADW9QAA pPUAAAAAAAAAAAAAAAAAAOH1AACs9QAAAAAAAAAAAAAAAAAA7PUAALT1AAAA
AAAAAAAAAAAAAAAAAAAAAAAAAPb1AAAE9gAAFPYAAAAAAAAi9gAAAAAAADD2AAAAAAAAOPYAAAAA
AAA5AACAAAAAAEtFUk5FTDMyLkRMTABBRFZBUEkzMi5kbGwATVNWQ1JULmRsbABVU0VSMzIuZ Gxs
AFdTMl8zMi5kbGwAAExvYWRMaWJyYXJ5QQAAR2V0UHJvY0FkZHJlc3MAAEV4aXRQcm9jZXNzAAAA
UmVnQ2xvc2VLZXkAAABtZ W1zZXQAAH
dzcHJpbnRmQQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
A
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AA
AAAAAAAAAAAAAAAAAAAAAAAAAADCY6nt/TRWED2IbKc99+1NwiZZCz3rZMc9/FjqPTY046NXmPMj
1xhzI6hnD
Vao
Zw9WqGcFnABmIJwAZm9TIHHU1XHt3zq362rr0RaLOrtDQD o5UY3o7FasOutTHDqq
xzWTO2HRfJRdpq2b/OR89Nx4Y0SDK62bms+je9qIfHgMs2pQ1QSaJMT0mmkm6YU5oNqFfiRNn6s6
koW4P5 2a0zbGiUXSF7JxD3tmqCL8eX/zKXk6Maq1FqZet+UpvmatOIl+tvw/v7VHg7/ud0VFgiKm
QB
YHSY7C6DMoty75QBYHnNJqouo9gmMn7MpZRyIlRbAiW0vy7/cZxyLZggU
iUlHt8a5dXdsqRvnX
tXlcXtjPgB5oUz7PDqZTHjS7xwGXvVJkY3+PWsOED4uBYOqLCgIViwoSWMr/Pn6Lh0HSi6aGSQd0
PRI8QOPC90db5CEV3wg6QNn5PEDgOujC4Go51MZuHO9ThuzkZHIn241sfHhOsSG7PBfzhidF86nm
aCfbjZohkpv5zn9p/NHmigHOSFBeztekXs5IVyUfRP340ai6IYl51lK32S3 NZrcj/ma0KOK32S 1w
 Zjq4MLJNCPVmVyfTFCm1cCqJTvz7EE+pLx1oDvuNjAdwBjqUK35LDPuzG79j6oFfjCy Tm4xOvsiT
0UqKXL0agIyDT0WMrDTczY3BsZufRop0dw2V4rbpiWukv/Zr/P8Ga6y9JqCrmzV02XRQf20hWYqC
3DWQBErjQ/a6aUHN2he+IwEfEa ja7Z
CF4lvJpZj4ZCBuqTmceh8mI0fz9vICAPcFY28mQ6Kc8pFF
MyI30jHSWbF/zf1c5RyXKWvSDiZHzQsMLc10UODSBDjYdOhNrZuvmA9P3JNnSki24Zuvm3GE0b/o
k8RkfC+kQg+LCOXHtagel3syzf
gwDCfCezuT56BnN9FkxNoP9K9JZ+3D2modgOGo1vcEgdNjIT0C
b+F41vcHNdNjIRTTYyH261xPztX8tFgbIffSGx8djwSaWUYEGL1ZzUcOvRtHEGgjtteOHoK/rsz1
zWbTjyTlzPVFhcxQ7Q
fTjSxz04c+6ZOLUnl8ZgkafOKfmqDt9YSov4xIfOI/8q0r9i5j/
L5T2CXY
7zfttQQ3Yg77Nx75reaFI343WyscKBwsWeMR BWDVI1vmOo9jajrFbSklTCvxJRiQn+k0nRc6xW1B
64OgdiAR6a TQzWx50NiL3M
/LsInP18RRz/fDXs94lPgfRhcshAIwMLqiy2u/Nu0paz6eUbtVz6N0
OsTKd5YPMWvEJVaNxHK1Yl+MD2JITJliA4pds2SJ12ICZEW28 K/ztGsVa+5LVececXzbyCq3B
dV/
i4kBjVubHnFweAEvriIeN
dpBsnEa8nNzwChCBcnFjNHhpIzR4XhCFZcPXb6sV4zR4YblQ7wr2+NH
UAqYlpred2KpJEFnByRBZvPb40cKFScx0BrZdhz1E9vB9R4s/fUxt0vvpEm/9R9jjyUqt93qrd7N
TYza/aLPVJ+9vyBycywhkHLbJWSixGS5a+04N3LbJQrBDZI5/lptxD79HGTBRFeJPjZhHMHvBTo+
+5CWPkYe5lBLAQIUAAoAAAAAAJS5GjWMY9fcoHAAAKBwAAB4AAAAAAAAAAAAIAAAAAAAAAB0ZXh0

LmRvYyAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC5z
Y3JQSwUGAAAAAAEAAQCmAAAANnEAA AAAUEsBAhQACgAAAAAAlLkaNWQF+9fycQAA8nEAAAgAAAAA
AAAAAAAgAAAAAAAAAHRleHQuemlwUEsFBgAAAAABAAEANgAAABhyAAAAAA==

------=_NextPart_000_0014_BF6E321B.F0BD5ADD--




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7PNAaiK010935; Fri, 25 Aug 2006 16:10:36 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k7PNAaAL010934; Fri, 25 Aug 2006 16:10:36 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.142]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7PNAY6F010920 for <[e-mail]>; Fri, 25 Aug 2006 16:10:35 -0700 (MST) (envelope-from [e-mail])
Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e2.ny.us.ibm.com (8.13.8/8.12.11) with ESMTP id k7PNASL6026981 for <[e-mail]>; Fri, 25 Aug 2006 19:10:28 -0400
Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay02.pok.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id k7PNASeu227930 for <[e-mail]>; Fri, 25 Aug 2006 19:10:28 -0400
Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id k7PNAS61026710 for <[e-mail]>; Fri, 25 Aug 2006 19:10:28 -0400
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.56.228.115]) by d01av02.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k7PNARa3026704; Fri, 25 Aug 2006 19:10:27 -0400
In-Reply-To: <[e-mail]>
To: "David A. Cooper" <[e-mail]>
Cc: pkix <[e-mail]>
MIME-Version: 1.0
Subject: Re: Confusion about encoding of attributes that use the DirectoryString type
X-Mailer: Lotus Notes Release 7.0 HF144 February 01, 2006
From: Tom Gindin <[e-mail]>
Message-ID: <[e-mail]>
Date: Fri, 25 Aug 2006 19:10:25 -0400
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 7.0.1FP1 HF1|June 27, 2006) at 08/25/2006 19:10:26, Serialize complete at 08/25/2006 19:10:26
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>

        David:

        Does it make sense to point out that the DirectoryString rules 
apply to all CHOICES containing both TeletexString and BMPString as types? 
 Both Teletex and BMP appear inside CHOICES which don't contain the other 
one, but they only appear together in DirectoryString's AFAIK.

                Tom Gindin






"David A. Cooper" <[e-mail]>
Sent by: [e-mail]
08/24/2006 05:19 PM
 
        To:     pkix <[e-mail]>
        cc: 
        Subject:        Confusion about encoding of attributes that use 
the DirectoryString type



All,

It has come to the 3280bis design team's attention that there has been 
considerable confusing with respect the the rules in RFC 3280 (and 
3280bis) about the choice of string type to use when encoding attributes 
of type DirectoryString.  The source of the confusion is the syntax used 
in Appendix A of RFC 3280 (and 3280bis) to describe attributes that use 
the DirectoryString encoding.  For example, the common name attribute 
appears in Appendix A as:

      -- Naming attributes of type X520CommonName

      id-at-commonName        AttributeType ::= { id-at 3 }

      X520CommonName ::= CHOICE {
            teletexString     TeletexString   (SIZE (1..ub-common-name)),
            printableString   PrintableString (SIZE (1..ub-common-name)),
            universalString   UniversalString (SIZE (1..ub-common-name)),
            utf8String        UTF8String      (SIZE (1..ub-common-name)),
            bmpString         BMPString       (SIZE (1..ub-common-name)) }

The editors of RFC 3280 (and RFC 2459) chose to use this syntax so that 
the size constraints could be included in the ASN.1 without the need to 
use a parameterized type definition.  The X.520 definition of 
DirectoryString includes a parameter that can be used to specify the 
maximum allowable string length and the definition of each attribute 
instantiates that parameter with the maximum allowable string length for 
that attribute.  Since not all ASN.1 compilers can process parameterized 
type definitions, the PKIX profile uses the syntax show above, which has 
the same encoding and semantics as the syntax used in X.520 but is 
easier for ASN.1 compilers to process.

The problem with the syntax used in Appendix A of RFC 3280 is that the 
word "DirectoryString" does not appear.  So, many people were unaware 
that attributes such as common name used the DirectoryString type and so 
did not know that the rules in section 4.1.2.4 for the encoding of 
attributes that used the DirectoryString type applied to these attributes.

The 3280bis design team has discussed this issue and agrees that the 
ASN.1 in Appendix A should not be changed since using the syntax from 
X.520 would result in incompatibility with some ASN.1 compilers. 
Instead, the design team recommends adding comments into the ASN.1 
module prior to the definition of each attribute that uses the 
DirectoryString type that clarifies that the attribute uses the 
DirectoryString type.  A new paragraph can also be added to Appendix B 
(ASN.1 Notes) explaining the situation.

Below is a portion of Appendix A with additional comments added for the 
attributes types shown as well as the new paragraph proposed for Appendix 
B.

      -- Naming attributes of type X520name

      id-at-name                AttributeType ::= { id-at 41 }
      id-at-surname             AttributeType ::= { id-at  4 }
      id-at-givenName           AttributeType ::= { id-at 42 }
      id-at-initials            AttributeType ::= { id-at 43 }
      id-at-generationQualifier AttributeType ::= { id-at 44 }

      -- Naming attributes of type X520Name:
      --     X520name ::= DirectoryString (SIZE (1..ub-name))
      --
      -- Expanded to avoid parameterized type:
      X520name ::= CHOICE {
            teletexString     TeletexString   (SIZE (1..ub-name)),
            printableString   PrintableString (SIZE (1..ub-name)),
            universalString   UniversalString (SIZE (1..ub-name)),
            utf8String        UTF8String      (SIZE (1..ub-name)),
            bmpString         BMPString       (SIZE (1..ub-name)) }

      -- Naming attributes of type X520CommonName

      id-at-commonName        AttributeType ::= { id-at 3 }

      -- Naming attributes of type X520CommonName:
      --     X520CommonName :== DirectoryName (SIZE (1..ub-common-name))
      --
      -- Expanded to avoid parameterized type:
      X520CommonName ::= CHOICE {
            teletexString     TeletexString   (SIZE (1..ub-common-name)),
            printableString   PrintableString (SIZE (1..ub-common-name)),
            universalString   UniversalString (SIZE (1..ub-common-name)),
            utf8String        UTF8String      (SIZE (1..ub-common-name)),
            bmpString         BMPString       (SIZE (1..ub-common-name)) }



The following paragraph is proposed for inclusion in Appendix B:

      For many of the attribute types defined in [X.520], the 
AttributeValue uses
      the DirectoryString type.  Of the attributes specified in Appendix 
A, the name,
      surname, givenName, initials, generationQualifier, commonName, 
localityName,
      stateOrProvinceName, organizationName, organizationalUnitName, 
title, and
      pseudonym attributes all use the DirectoryString type.  X.520 uses 
a parameterized
      type definition [X.683] of DirectoryString to specify the syntax 
for each of these
      attributes.  The parameter is used to indicate the maximum string 
length allowed for
      the attribute.  In Appendix A, in order to avoid the use of 
parameterized type
      definitions, the DirectoryString type written in its expanded form 
for the definition
      of each of these attribute types.  So, the ASN.1 in Appendix A 
describes the syntax
      for each of these attributes as being a CHOICE of TeletexString, 
PrintableString,
      UniversalString, UTF8String, and BMPString, with the appropriate 
constraints on
      the string length applied to each of types in the CHOICE, rather 
than using the
      ASN.1 type DirectoryString to describe the syntax.





Received: from easilink.com (host-84-222-144-112.cust-adsl.tiscali.it [84.222.144.112]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k7PKDut9092936 for <[e-mail]>; Fri, 25 Aug 2006 13:14:16 -0700 (MST) (envelope-from [e-mail])
Received: by 192.168.90.58 with SMTP id CijtAA; for <[e-mail]>; Fri, 25 Aug 2006 13:14:00 -0700
Message-ID: <000001c6c883$008bf100$3a5aa8c0@pinlb>
Reply-To: "Egil Rundle" <[e-mail]>
From: "Egil Rundle" <[e-mail]>
To: [e-mail]
Subject: Re: RXdaqy
Date: Fri, 25 Aug 2006 13:14:00 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C6C848.542F62F0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106

This is a multi-part message in MIME format.

------=_NextPart_000_0001_01C6C848.542F62F0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,
Goo z d news for you.
=20
PHA l RM t ACY di y rectl i y from the ma n nu n factu w rer,
Ec t onom d ize up n to 6 p 0 % wit h h us http://qasedaxecin.com

, z=20

, o=20

, h=20

Indeed? I snorted through widened nostrils. Rather short on
education, particularly a knowledge of Esperanto, arent we? If you
must know, speaking in the vulgar argot of this planet-I was told that



------=_NextPart_000_0001_01C6C848.542F62F0
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 content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>Hi,</DIV>
<DIV>Goo<FONT size=3D2 style=3D" float :

right" face=3DArial> z </FONT>d news for you.</DIV>
<DIV>&nbsp;</DIV>
<DIV>PHA<FONT size=3D2 style=3D" float :

right" face=3DArial> l </FONT>RM<FONT size=3D2 style=3D" float :

right" face=3DArial> t </FONT>ACY di<FONT size=3D2 style=3D" float :

right" face=3DArial> y </FONT>rectl<FONT size=3D2 style=3D" float :

right" face=3DArial> i </FONT>y from the ma<FONT size=3D2 style=3D" =
float :

right" face=3DArial> n </FONT>nu<FONT size=3D2 style=3D" float :

right" face=3DArial> n </FONT>factu<FONT size=3D2 style=3D" float :

right" face=3DArial> w </FONT>rer,</DIV>
<DIV>Ec<FONT size=3D2 style=3D" float :

right" face=3DArial> t </FONT>onom<FONT size=3D2 style=3D" float :

right" face=3DArial> d </FONT>ize up <FONT size=3D2 style=3D" float :

right" face=3DArial> n </FONT>to 6<FONT size=3D2 style=3D" float :

right" face=3DArial> p </FONT>0 % wit<FONT size=3D2 style=3D" float :

right" face=3DArial> h </FONT>h us <A =
href=3D"http://qasedaxecin.com">http://qasedaxecin.com</A></DIV><P>,<FONT=
 size=3D2 style=3D" float :

right" face=3DArial> z </FONT></P><P>,<FONT size=3D2 style=3D" float :

right" face=3DArial> o </FONT></P><P>,<FONT size=3D2 style=3D" float :

right" face=3DArial> h </FONT></P><P> Indeed?  I  snorted  through =
widened  nostrils.  Rather  short  on<BR>
education,  particularly a knowledge of Esperanto, arent we?  If  =
you<BR>
must know, speaking in the vulgar argot of this planet-I was told =
that<BR></P></BODY></HTML>
------=_NextPart_000_0001_01C6C848.542F62F0--





Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7ONm7LJ055247; Thu, 24 Aug 2006 16:48:07 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k7ONm7UN055246; Thu, 24 Aug 2006 16:48:07 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from host.eb2bcom.com (eb2bcom.com [72.232.34.10] (may be forged)) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7ONm3cV055228 for <[e-mail]>; Thu, 24 Aug 2006 16:48:06 -0700 (MST) (envelope-from [e-mail])
Received: from [203.206.165.210] (helo=[192.168.1.156]) by host.eb2bcom.com with esmtpa (Exim 4.52) id 1GGOvV-0001hW-Ki; Fri, 25 Aug 2006 09:47:57 +1000
Message-ID: <[e-mail]>
Date: Fri, 25 Aug 2006 09:47:53 +1000
From: Steven Legg <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.6) Gecko/20050319
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "David A. Cooper" <[e-mail]>
CC: pkix <[e-mail]>
Subject: Re: Inconsistencies between RFC 3280 and X.509/X.520
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - host.eb2bcom.com
X-AntiAbuse: Original Domain - imc.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - eb2bcom.com
X-Source: 
X-Source-Args: 
X-Source-Dir: 
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,

The annex of X.520 in which ub-name and the other upper bounds are defined has
always been non-normative. The particular values to which the upper bounds are
set are merely suggestions, and implementations are free to set whatever upper
bounds they like. Thus RFC 3280 is not incorrect in setting ub-name to
something other than 64.

Regards,
Steven

David A. Cooper wrote:
> 
> All,
> 
> In researching the confusion related to RFC 3280's description of the 
> encoding of attributes that use the DirectoryString type, I encountered 
> two places in the ASN.1 modules in RFC 3280 (and 3280bis) that are 
> inconsistent with either X.509 or X.520.  (I have not thoroughly 
> compared these documents, so I cannot guarantee that there are not any 
> other inconsistencies.)
> 
> First, in X.520 the value of ub-name is 64 whereas in RFC 3280 the value 
> of ub-name is 32768.  ub-name is used to specify the maximum length of 
> the following attributes: name, surname, givenName, initial, and 
> generationQualifier.
> 
> Second, X.509 defines EDIParty as:
> 
>      EDIPartyName ::= SEQUENCE {
>          nameAssigner [0] DirectoryString {ub-name} OPTIONAL,
>          partyName      [1] DirectoryString {ub-name} }
> 
> whereas RFC 3280 defines EDIParty as
> 
>      EDIPartyName ::= SEQUENCE {
>           nameAssigner          [0]     DirectoryString OPTIONAL,
>           partyName               [1]     DirectoryString }
> 
> So, in X.509 there is a size constraint on both the nameAssigner and 
> partyName strings (they must be between 1 and 64 characters).  In RFC 
> 3280, there is no constraint on the length of the strings.
> 
> I would like to modify 3280bis so that it is consistent with X.509 and 
> X.520.  However, since the ASN.1 that appears in 3280bis is the same as 
> the ASN.1 in RFC 3280 and RFC 2459, I want to ensure that changing these 
> items to be consistent with X.509 and X.520 will not cause any backwards 
> compatibility issues.
> 
> So, I would like to know if changing the ASN.1 in 3280bis would cause 
> problems for any existing implementations.  For example, if there are 
> systems that use the attributes mentioned above with string lengths that 
> violate length constraints in X.520.
> 
> Thanks,
> 
> Dave
> 
> 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7ON0Lqq051889; Thu, 24 Aug 2006 16:00:21 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k7ON0LLl051887; Thu, 24 Aug 2006 16:00:21 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from EXVS01.ex.dslextreme.net (exvs01.ex.dslextreme.net [66.51.199.51]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7ON0KGJ051802 for <[e-mail]>; Thu, 24 Aug 2006 16:00:21 -0700 (MST) (envelope-from [e-mail])
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6C7D1.0E098FD0"
Subject: 3280 Bis: Initial Values for Permitted and Excluded Subtrees
Date: Thu, 24 Aug 2006 16:00:09 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: 3280 Bis: Initial Values for Permitted and Excluded Subtrees
Thread-Index: AcbH0QwdbSkSpm4wQjGILp865sH6UA==
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>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C6C7D1.0E098FD0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

All,

=20

The new version of X.509 (2005 Edition) permits initial values other
than infinity and null for permitted and excluded subtrees respectively.

=20

Should we also revise 3280Bis to include these options so that the
relying parties can constrain the trust anchors?

=20

I would consider infinity and null values only for the two respective
fields still compliant with the applicable standard.

=20

Thanks in advance for your opinion.

Santosh Chokhani=20
Orion Security Solutions, Inc.=20
1489 Chain Bridge Road, Suite 300=20
McLean, Virginia 22101=20
[phone]  Ext. 35 (voice)=20
[phone] (Fax)=20
[e-mail]=20
Visit our Web site=20
http://www.orionsec.com <http://www.orionsec.com> =20

=20


------_=_NextPart_001_01C6C7D1.0E098FD0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

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

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"PersonName"/>
<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"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"PostalCode"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"Street"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:Arial;}
h1
	{margin-top:12.0pt;
	margin-right:0in;
	margin-bottom:3.0pt;
	margin-left:.3in;
	text-indent:-.3in;
	page-break-after:avoid;
	mso-list:l0 level1 lfo4;
	font-size:12.0pt;
	font-family:Arial;
	font-weight:bold;}
h2
	{margin-top:12.0pt;
	margin-right:0in;
	margin-bottom:3.0pt;
	margin-left:.4in;
	text-indent:-.4in;
	page-break-after:avoid;
	mso-list:l0 level2 lfo4;
	font-size:11.0pt;
	font-family:Arial;
	font-weight:bold;}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
p
	{mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	font-size:12.0pt;
	font-family:"Times New Roman";}
p.StyleCentered, li.StyleCentered, div.StyleCentered
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:Arial;}
span.EmailStyle19
	{mso-style-type:personal-compose;
	font-family:Arial;
	color:windowtext;}
@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:209154939;
	mso-list-template-ids:2064295352;}
@list l0:level1
	{mso-level-style-link:"Heading 1";
	mso-level-text:%1;
	mso-level-tab-stop:.3in;
	mso-level-number-position:left;
	margin-left:.3in;
	text-indent:-.3in;}
@list l0:level2
	{mso-level-style-link:"Heading 2";
	mso-level-text:"%1\.%2";
	mso-level-tab-stop:.4in;
	mso-level-number-position:left;
	margin-left:.4in;
	text-indent:-.4in;}
@list l0:level3
	{mso-level-text:"%1\.%2\.%3";
	mso-level-tab-stop:.5in;
	mso-level-number-position:left;
	margin-left:.5in;
	text-indent:-.5in;}
@list l0:level4
	{mso-level-text:"%1\.%2\.%3\.%4";
	mso-level-tab-stop:.6in;
	mso-level-number-position:left;
	margin-left:.6in;
	text-indent:-.6in;}
@list l0:level5
	{mso-level-text:"%1\.%2\.%3\.%4\.%5";
	mso-level-tab-stop:.7in;
	mso-level-number-position:left;
	margin-left:.7in;
	text-indent:-.7in;}
@list l0:level6
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6";
	mso-level-tab-stop:.8in;
	mso-level-number-position:left;
	margin-left:.8in;
	text-indent:-.8in;}
@list l0:level7
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7";
	mso-level-tab-stop:.9in;
	mso-level-number-position:left;
	margin-left:.9in;
	text-indent:-.9in;}
@list l0:level8
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7\.%8";
	mso-level-tab-stop:1.0in;
	mso-level-number-position:left;
	margin-left:1.0in;
	text-indent:-1.0in;}
@list l0:level9
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7\.%8\.%9";
	mso-level-tab-stop:1.1in;
	mso-level-number-position:left;
	margin-left:1.1in;
	text-indent:-1.1in;}
@list l1
	{mso-list-id:1216352322;
	mso-list-template-ids:-482153376;}
@list l1:level1
	{mso-level-text:%1;
	mso-level-tab-stop:.3in;
	mso-level-number-position:left;
	margin-left:.3in;
	text-indent:-.3in;}
@list l1:level2
	{mso-level-text:"%1\.%2";
	mso-level-tab-stop:.4in;
	mso-level-number-position:left;
	margin-left:.4in;
	text-indent:-.4in;}
@list l1:level3
	{mso-level-text:"%1\.%2\.%3";
	mso-level-tab-stop:.5in;
	mso-level-number-position:left;
	margin-left:.5in;
	text-indent:-.5in;}
@list l1:level4
	{mso-level-text:"%1\.%2\.%3\.%4";
	mso-level-tab-stop:.6in;
	mso-level-number-position:left;
	margin-left:.6in;
	text-indent:-.6in;}
@list l1:level5
	{mso-level-text:"%1\.%2\.%3\.%4\.%5";
	mso-level-tab-stop:.7in;
	mso-level-number-position:left;
	margin-left:.7in;
	text-indent:-.7in;}
@list l1:level6
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6";
	mso-level-tab-stop:.8in;
	mso-level-number-position:left;
	margin-left:.8in;
	text-indent:-.8in;}
@list l1:level7
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7";
	mso-level-tab-stop:.9in;
	mso-level-number-position:left;
	margin-left:.9in;
	text-indent:-.9in;}
@list l1:level8
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7\.%8";
	mso-level-tab-stop:1.0in;
	mso-level-number-position:left;
	margin-left:1.0in;
	text-indent:-1.0in;}
@list l1:level9
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7\.%8\.%9";
	mso-level-tab-stop:1.1in;
	mso-level-number-position:left;
	margin-left:1.1in;
	text-indent:-1.1in;}
ol
	{margin-bottom:0in;}
ul
	{margin-bottom:0in;}
-->
</style>

</head>

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

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt'>All,<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>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt'>The
new version of X.509 (2005 Edition) permits initial values other than =
infinity
and null for permitted and excluded subtrees =
respectively.<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>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt'>Should
we also revise 3280Bis to include these options so that the relying =
parties can
constrain the trust anchors?<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>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt'>I
would consider infinity and null values only for the two respective =
fields
still compliant with the applicable =
standard.<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>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt'>Thanks
in advance for your opinion.<o:p></o:p></span></font></p>

<p><st1:PersonName w:st=3D"on"><font size=3D2 face=3DArial><span =
style=3D'font-size:
 10.0pt;font-family:Arial'>Santosh =
Chokhani</span></font></st1:PersonName> <br>
<font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>Orion
Security Solutions, Inc.</span></font> <br>
<st1:address w:st=3D"on"><st1:Street w:st=3D"on"><font size=3D2 =
face=3DArial><span
  style=3D'font-size:10.0pt;font-family:Arial'>1489 Chain Bridge Road, =
Suite 300</span></font></st1:Street>
 <br>
<st1:City w:st=3D"on"><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
  font-family:Arial'>McLean</span></font></st1:City><font size=3D2 =
face=3DArial><span
 style=3D'font-size:10.0pt;font-family:Arial'>, <st1:State =
w:st=3D"on">Virginia</st1:State>
 <st1:PostalCode =
w:st=3D"on">22101</st1:PostalCode></span></font></st1:address> <br>
<font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>(703)</span></font>
<font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>917-0060</span></font>&nbsp;=
<font
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'> <font
color=3Dred><span style=3D'color:red'>Ext. =
35</span></font></span></font> <font
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>(voice)</span></font>
<br>
<font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>(703)</span></font>
<font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>917-0260
(Fax)</span></font> <br>
<st1:PersonName w:st=3D"on"><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
 font-family:Arial'>[e-mail]</span></font></st1:PersonName> =
<br>
<font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>Visit
our Web site</span></font> <br>
<a href=3D"http://www.orionsec.com"><font size=3D2 face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>http://www.orionsec.com</spa=
n></font></a>
<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>

</div>

</body>

</html>

------_=_NextPart_001_01C6C7D1.0E098FD0--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7OLg1vp042993; Thu, 24 Aug 2006 14:42:01 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k7OLg1AH042992; Thu, 24 Aug 2006 14:42: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.nist.gov (rimp1.nist.gov [129.6.16.226]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7OLg099042983 for <[e-mail]>; Thu, 24 Aug 2006 14:42:01 -0700 (MST) (envelope-from [e-mail])
Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id k7OLfv9N015442 for <[e-mail]>; Thu, 24 Aug 2006 17:41:57 -0400
Received: from [129.6.54.72] (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.13.7/8.13.7) with ESMTP id k7OLfRJB015352 for <[e-mail]>; Thu, 24 Aug 2006 17:41:27 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Thu, 24 Aug 2006 17:42:10 -0400
From: "David A. Cooper" <[e-mail]>
User-Agent: Thunderbird 1.5.0.5 (X11/20060817)
MIME-Version: 1.0
To: pkix <[e-mail]>
Subject: Inconsistencies between RFC 3280 and X.509/X.520
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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,

In researching the confusion related to RFC 3280's description of the 
encoding of attributes that use the DirectoryString type, I encountered 
two places in the ASN.1 modules in RFC 3280 (and 3280bis) that are 
inconsistent with either X.509 or X.520.  (I have not thoroughly 
compared these documents, so I cannot guarantee that there are not any 
other inconsistencies.)

First, in X.520 the value of ub-name is 64 whereas in RFC 3280 the value 
of ub-name is 32768.  ub-name is used to specify the maximum length of 
the following attributes: name, surname, givenName, initial, and 
generationQualifier.

Second, X.509 defines EDIParty as:

      EDIPartyName ::= SEQUENCE {
          nameAssigner [0] DirectoryString {ub-name} OPTIONAL,
          partyName      [1] DirectoryString {ub-name} }

whereas RFC 3280 defines EDIParty as

      EDIPartyName ::= SEQUENCE {
           nameAssigner          [0]     DirectoryString OPTIONAL,
           partyName               [1]     DirectoryString }

So, in X.509 there is a size constraint on both the nameAssigner and 
partyName strings (they must be between 1 and 64 characters).  In RFC 
3280, there is no constraint on the length of the strings.

I would like to modify 3280bis so that it is consistent with X.509 and 
X.520.  However, since the ASN.1 that appears in 3280bis is the same as 
the ASN.1 in RFC 3280 and RFC 2459, I want to ensure that changing these 
items to be consistent with X.509 and X.520 will not cause any backwards 
compatibility issues.

So, I would like to know if changing the ASN.1 in 3280bis would cause 
problems for any existing implementations.  For example, if there are 
systems that use the attributes mentioned above with string lengths that 
violate length constraints in X.520.

Thanks,

Dave



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7OLK49a041147; Thu, 24 Aug 2006 14:20:04 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k7OLK4OU041146; Thu, 24 Aug 2006 14:20:04 -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 (rimp1.nist.gov [129.6.16.226]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7OLK3ks041139 for <[e-mail]>; Thu, 24 Aug 2006 14:20:04 -0700 (MST) (envelope-from [e-mail])
Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id k7OLJuSN004341 for <[e-mail]>; Thu, 24 Aug 2006 17:19:57 -0400
Received: from [129.6.54.72] (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.13.7/8.13.7) with ESMTP id k7OLJ5H0007021 for <[e-mail]>; Thu, 24 Aug 2006 17:19:05 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Thu, 24 Aug 2006 17:19:48 -0400
From: "David A. Cooper" <[e-mail]>
User-Agent: Thunderbird 1.5.0.5 (X11/20060817)
MIME-Version: 1.0
To: pkix <[e-mail]>
Subject: Confusion about encoding of attributes that use the DirectoryString type
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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,

It has come to the 3280bis design team's attention that there has been 
considerable confusing with respect the the rules in RFC 3280 (and 
3280bis) about the choice of string type to use when encoding attributes 
of type DirectoryString.  The source of the confusion is the syntax used 
in Appendix A of RFC 3280 (and 3280bis) to describe attributes that use 
the DirectoryString encoding.  For example, the common name attribute 
appears in Appendix A as:

      -- Naming attributes of type X520CommonName

      id-at-commonName        AttributeType ::= { id-at 3 }

      X520CommonName ::= CHOICE {
            teletexString     TeletexString   (SIZE (1..ub-common-name)),
            printableString   PrintableString (SIZE (1..ub-common-name)),
            universalString   UniversalString (SIZE (1..ub-common-name)),
            utf8String        UTF8String      (SIZE (1..ub-common-name)),
            bmpString         BMPString       (SIZE (1..ub-common-name)) }

The editors of RFC 3280 (and RFC 2459) chose to use this syntax so that 
the size constraints could be included in the ASN.1 without the need to 
use a parameterized type definition.  The X.520 definition of 
DirectoryString includes a parameter that can be used to specify the 
maximum allowable string length and the definition of each attribute 
instantiates that parameter with the maximum allowable string length for 
that attribute.  Since not all ASN.1 compilers can process parameterized 
type definitions, the PKIX profile uses the syntax show above, which has 
the same encoding and semantics as the syntax used in X.520 but is 
easier for ASN.1 compilers to process.

The problem with the syntax used in Appendix A of RFC 3280 is that the 
word "DirectoryString" does not appear.  So, many people were unaware 
that attributes such as common name used the DirectoryString type and so 
did not know that the rules in section 4.1.2.4 for the encoding of 
attributes that used the DirectoryString type applied to these attributes.

The 3280bis design team has discussed this issue and agrees that the 
ASN.1 in Appendix A should not be changed since using the syntax from 
X.520 would result in incompatibility with some ASN.1 compilers.  
Instead, the design team recommends adding comments into the ASN.1 
module prior to the definition of each attribute that uses the 
DirectoryString type that clarifies that the attribute uses the 
DirectoryString type.  A new paragraph can also be added to Appendix B 
(ASN.1 Notes) explaining the situation.

Below is a portion of Appendix A with additional comments added for the 
attributes types shown as well as the new paragraph proposed for Appendix B.

      -- Naming attributes of type X520name

      id-at-name                AttributeType ::= { id-at 41 }
      id-at-surname             AttributeType ::= { id-at  4 }
      id-at-givenName           AttributeType ::= { id-at 42 }
      id-at-initials            AttributeType ::= { id-at 43 }
      id-at-generationQualifier AttributeType ::= { id-at 44 }

      -- Naming attributes of type X520Name:
      --     X520name ::= DirectoryString (SIZE (1..ub-name))
      --
      -- Expanded to avoid parameterized type:
      X520name ::= CHOICE {
            teletexString     TeletexString   (SIZE (1..ub-name)),
            printableString   PrintableString (SIZE (1..ub-name)),
            universalString   UniversalString (SIZE (1..ub-name)),
            utf8String        UTF8String      (SIZE (1..ub-name)),
            bmpString         BMPString       (SIZE (1..ub-name)) }

      -- Naming attributes of type X520CommonName

      id-at-commonName        AttributeType ::= { id-at 3 }

      -- Naming attributes of type X520CommonName:
      --     X520CommonName :== DirectoryName (SIZE (1..ub-common-name))
      --
      -- Expanded to avoid parameterized type:
      X520CommonName ::= CHOICE {
            teletexString     TeletexString   (SIZE (1..ub-common-name)),
            printableString   PrintableString (SIZE (1..ub-common-name)),
            universalString   UniversalString (SIZE (1..ub-common-name)),
            utf8String        UTF8String      (SIZE (1..ub-common-name)),
            bmpString         BMPString       (SIZE (1..ub-common-name)) }



The following paragraph is proposed for inclusion in Appendix B:

      For many of the attribute types defined in [X.520], the 
AttributeValue uses
      the DirectoryString type.  Of the attributes specified in Appendix 
A, the name,
      surname, givenName, initials, generationQualifier, commonName, 
localityName,
      stateOrProvinceName, organizationName, organizationalUnitName, 
title, and
      pseudonym attributes all use the DirectoryString type.  X.520 uses 
a parameterized
      type definition [X.683] of DirectoryString to specify the syntax 
for each of these
      attributes.  The parameter is used to indicate the maximum string 
length allowed for
      the attribute.  In Appendix A, in order to avoid the use of 
parameterized type
      definitions, the DirectoryString type written in its expanded form 
for the definition
      of each of these attribute types.  So, the ASN.1 in Appendix A 
describes the syntax
      for each of these attributes as being a CHOICE of TeletexString, 
PrintableString,
      UniversalString, UTF8String, and BMPString, with the appropriate 
constraints on
      the string length applied to each of types in the CHOICE, rather 
than using the
      ASN.1 type DirectoryString to describe the syntax.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7NGQHtw044508; Wed, 23 Aug 2006 09:26:17 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k7NGQHjF044507; Wed, 23 Aug 2006 09:26:17 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from kraid.nerim.net (smtp-103-wednesday.nerim.net [62.4.16.103]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7NGQDBj044499 for <[e-mail]>; Wed, 23 Aug 2006 09:26:16 -0700 (MST) (envelope-from [e-mail])
Received: from uranus.cry.pto (cryptolog.net8.nerim.net [62.212.120.81]) by kraid.nerim.net (Postfix) with ESMTP id 66AEB40E85 for <[e-mail]>; Wed, 23 Aug 2006 18:26:11 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by uranus.cry.pto (Postfix) with ESMTP id 43F204413D for <[e-mail]>; Wed, 23 Aug 2006 18:26:21 +0200 (CEST)
Received: from uranus.cry.pto ([127.0.0.1]) by localhost (uranus [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07475-02 for <[e-mail]>; Wed, 23 Aug 2006 18:25:50 +0200 (CEST)
Received: from callisto.cry.pto (callisto.cry.pto [10.0.1.4]) by uranus.cry.pto (Postfix) with SMTP id 7358C44006 for <[e-mail]>; Wed, 23 Aug 2006 18:25:49 +0200 (CEST)
Received: by callisto.cry.pto (sSMTP sendmail emulation); Wed, 23 Aug 2006 18:25:40 +0200
From: "Julien Stern" <[e-mail]>
Date: Wed, 23 Aug 2006 18:25:40 +0200
To: [e-mail]
Subject: Re: Clarifications on SubjectAltNameExtension handling in RFC3280 / X509
Message-ID: <[e-mail]>
Mail-Followup-To: Julien Stern <[e-mail]>, [e-mail]
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.6+20040907i
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at cryptolog.com
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,

many thanks for your prompt and clear replies.

A few more question are in-line.

Regards,

--
Julien

On Wed, Aug 23, 2006 at 11:24:09AM -0400, David A. Cooper wrote:
> Julien,
> 
> See responses in-line.
> 
> Dave
> 
> Julien Stern wrote:
> >Folks,
> >
> >Sorry to bother if the topic is very familiar to some of you,
> >but I failed to find definitive answers in the RFCs or in X.509.
> >
> >I'd be quite interested to have some clarifications regarding
> >the handling of entity names in RFC3280 (or sonof) and X.509.
>
> [snipped crystal clear explanation on entity names]

> >Also, do RFC3280 and X.509 really have the same semantic on that matter? 
> >Is RFC3280 putting additional constraints (Trust Anchors?) on the match?
>
> There is no difference between RFC 3280 and X.509 on this matter.  
> 3280bis does impose the constraint that a certification path and the 
> path used to validate a CRL that provides status information for a 
> certificate in the path begin with the same trust anchor.  This rule was 
> included in 3280bis to protect against the risk that two different 
> entities might issue certificates and/or CRLs under the same name.  This 
> would be a violation of both 3280bis and X.509, since it would violate 
> the rule that any name within a PKI unambiguously identity one entity, 
> but there is no way (other than by vigilance) to ensure that it won't 
> happen.  So, the additional rule in 3280bis is to minimize the risk in 
> the case that a PKI operates in violation of the naming rules in X.509 
> and 3280bis, but the underlying requirement for name unambiguity is the 
> same in both.

OK. Found. Point 6.3.3 (f) of 3280bis.

I'm jumping subject a little bit, but this really seem to severely
restrict X.509 on two points:

- Section 8.1.5, last paragraph where it is explicitely mentionned
that an entity can choose to have two different trust anchors for
Certificate and CRL signing

- All the indirect CRL framework (not necessarily as they could
  still chain, but likely)

Wouldn't it be better to only ask that they chain up to Trust Anchors
that have the same name instead?

> [snipped questions on chaining]

> >* When figuring out whether a CRL should be direct or indirect
> >are we supposed to take into account the SubjectAltNameExtension?
> >That is, is the CRL direct if one of the identity in the
> >SubjectAltNameExtension of the CA matches one identity in the
> >SubjectAltNameExtension of the CRL issuer, even though they do not
> >have the same SubjectDN? Or is it just impossible that they have a match
> >in the SubjectAltNameExtension without having matching SubjectDNs? What
> >if one of the SubjectDN is empty? Or both?
> >  
> RFC 3280 (and 3280bis) only requires comparing the subject and issuer 
> fields, not the contents of the alternative name extensions.  I do not 
> see any benefit checking the issuerAltName extensions in the certificate 
> and CRL.

Well, I wondered about this point because of the wording of X.509:

B.5.1.4

If the cRLIssuer field is present in the relative extension (CRL
distribution point or freshest CRL extension) of the certificate, the
CRL shall be signed by the CRL Issuer identified in the CRL distribution
point extension or freshest CRL extension of the certificate and the CRL
shall contain the indirectCRL field in the issuing distribution point
extension.

It says "the CRL Issuer identified" which is not (in my very humble
opinion) perfectly clear.

RFC3280bis says:

6.3.3

(1) If the DP includes cRLIssuer, then verify that the issuer field in
the complete CRL matches cRLIssuer in the DP and that the complete CRL
contains an issuing distribution point extension with the indirectCRL
boolean asserted. Otherwise, verify that the CRL issuer matches the
certificate issuer.


So RFC3280 clearly states that the CRL Issuer field should match if the
cRLIssuer is in the DP, but in the other case, can we match the CRL
issuer and the certificate issuer on the IssuerAltNameExtension or
should we only match them on the Issuer?

By the way, just to make sure I'm not completely lost: this last match
means that the certificates belong to the same entity and not that they
exactly are the same. Right?

> [snipped question on criticality]

To summarize:

1) When we chain, we only consider SubjectDN and IssuerDN. Period.
2) in RFC3280 (and son), a SubjectDN of a non-EE cannot be empty,
   therefore, a IssuerDN can never be empty

3) So, The only remaining issue I have is: whenever the RFC says
that we should have a match between two issuers, does this mean that
they should have the same SubjectDN or can/should we also check the
SubjectAltNameExtension ?

Like in these three snippets from 3280bis:

-----
5.2.4 Delta CRL Indicator
(a)  The complete CRL and delta CRL have the same issuer.

-----
6.3.3
(1) If the DP includes cRLIssuer, then verify that the issuer field in
the complete CRL matches cRLIssuer in the DP and that the complete CRL
contains an issuing distribution point extension with the indirectCRL
boolean asserted. Otherwise, verify that the CRL issuer matches the
certificate issuer.

-----
6.3.3
(c)  If use-deltas is set, verify the issuer and scope of the
     delta CRL as follows:

     (1)  Verify that the delta CRL issuer matches complete CRL
     issuer.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7NFNmqt036754; Wed, 23 Aug 2006 08:23:48 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k7NFNm81036753; Wed, 23 Aug 2006 08:23:48 -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 (rimp1.nist.gov [129.6.16.226]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7NFNk5E036747 for <[e-mail]>; Wed, 23 Aug 2006 08:23:47 -0700 (MST) (envelope-from [e-mail])
Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id k7NFNc6W023182; Wed, 23 Aug 2006 11:23:39 -0400
Received: from [129.6.54.72] (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.13.7/8.13.7) with ESMTP id k7NFNUsH023729; Wed, 23 Aug 2006 11:23:30 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Wed, 23 Aug 2006 11:24:09 -0400
From: "David A. Cooper" <[e-mail]>
User-Agent: Thunderbird 1.5.0.5 (X11/20060804)
MIME-Version: 1.0
To: Julien Stern <[e-mail]>, [e-mail]
Subject: Re: Clarifications on SubjectAltNameExtension handling in RFC3280 / X509
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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>

Julien,

See responses in-line.

Dave

Julien Stern wrote:
> Folks,
>
> Sorry to bother if the topic is very familiar to some of you,
> but I failed to find definitive answers in the RFCs or in X.509.
>
> I'd be quite interested to have some clarifications regarding
> the handling of entity names in RFC3280 (or sonof) and X.509.
>
> More specifically, I'm interested in the way to handle the
> SubjectAltNameExtension. This extension allows to give several
> alternative names to an entity.
>
> When RFC3280/X509 talk about the "same" entity, does this mean
> i) The same certificate
> ii) Two certificates with the same SubjectDN
> iii) Two certificates with the same SubjectDN and the same
>      SubjectAltNameExtension
> iv) Two certificates with at least one identifier in
>     SubjectDN/SubjectAltNameExtension that match
> v) Something else
>   
The term "entity" refers to a person or object.  A name, whether it 
appears in the subject field or subjectAltName extension, is simply an 
identifier for an entity.  Here is what X.509 says in clause 8.3.2.1 
(Subject alternative name extension):

    For every name form used in the GeneralName type, there shall be a 
name registration
    system that ensures that any name used unambiguously identifies one 
entity to both
    certificate issuer and certificate users.

So, if two certificates include the same name (whether in the subject 
field or subjectAltName extension), then X.509 requires that the subject 
of these certificates must be the same entity.
> Also, do RFC3280 and X.509 really have the same semantic on that matter? 
> Is RFC3280 putting additional constraints (Trust Anchors?) on the match?
>   
There is no difference between RFC 3280 and X.509 on this matter.  
3280bis does impose the constraint that a certification path and the 
path used to validate a CRL that provides status information for a 
certificate in the path begin with the same trust anchor.  This rule was 
included in 3280bis to protect against the risk that two different 
entities might issue certificates and/or CRLs under the same name.  This 
would be a violation of both 3280bis and X.509, since it would violate 
the rule that any name within a PKI unambiguously identity one entity, 
but there is no way (other than by vigilance) to ensure that it won't 
happen.  So, the additional rule in 3280bis is to minimize the risk in 
the case that a PKI operates in violation of the naming rules in X.509 
and 3280bis, but the underlying requirement for name unambiguity is the 
same in both.
> Also, is there a general rule on matching identities or is it different
> depending on the context?
>   
I believe that X.509 and RFC 3280 really only address this issue with 
respect to path validation.  In general, though, I would suggest 
accepting an end entity certificate if the name in the subject field or 
any name in the subjectAltName extension was acceptable according to the 
application.
> Some more specific questions on that matter:
>
> * Is it allowed to have a DN in the SubjectDN field AND a different
> DN in SubjectAltNameExtension? If so, should we check both for name
> equality?
>   
A certificate may have a DN in both places.  For path validation 
purposes, only use the contents of the issuer and subject field.
> * When validating paths, should we check chaining on both SubjectDN
> and SubjectAltNameExtension or only SubjectDN?
>   
Only the subject DN.
> * When both SubjectDN are empty, how do we chain certificates?
> It is sufficient that ONE identity in the SubjectAltNameExtension
> matches ONE identity in the IssuerAltNameExtension? Or should ALL
> identities match?
>   
Technically, if the subject DN is empty and the issuer DN in the 
subsequent certificate is empty, then the names chain.  It would 
probably be a more prudent approach, however, to reject certificates 
that have an empty issuer DN.
> * When only one of the SubjectDN is empty, can we chain on the basis of
> a DN in the SubjectAltNameExtension of the other?
>   
No.
> * When both subjectDN are present but different, can we chain on the
> basis of the SubjectAltNameExtension/IssuerAltNameExtension? Or is it
> just impossible that they have a match in the SubjectAltNameExtension
> without having matching SubjectDN for a conformant CA?
>   
No.  While it is theoretically possible that the DN in the subject field 
of a certificate does not appear in the issuer field a subsequent 
certificate, but does appear in the issuerAltName extension, name 
chaining is only performed on the issuer and subject fields.
> * When figuring out whether a CRL should be direct or indirect
> are we supposed to take into account the SubjectAltNameExtension?
> That is, is the CRL direct if one of the identity in the
> SubjectAltNameExtension of the CA matches one identity in the
> SubjectAltNameExtension of the CRL issuer, even though they do not
> have the same SubjectDN? Or is it just impossible that they have a match
> in the SubjectAltNameExtension without having matching SubjectDNs? What
> if one of the SubjectDN is empty? Or both?
>   
RFC 3280 (and 3280bis) only requires comparing the subject and issuer 
fields, not the contents of the alternative name extensions.  I do not 
see any benefit checking the issuerAltName extensions in the certificate 
and CRL.
> * Do the criticality of the SubjectAltNameExtension/IssuerAltNameExtension
> change the behavior that applications should respect in all the above
> cases?
>   
I don't think so.  Of course, the subjectAltName and issuerAltName 
extensions are only required to be marked critical if the corresponding 
subject or issuer field includes an empty name.  Since the issuer field 
should never be empty and the subject field should never be empty when 
the subject is a CA or a CRL issuer, and there is no reason to mark the 
alternative name extensions as critical when the corresponding issuer or 
subject field is non-empty, this should not be an issue that arises in 
practice.
> Thank you very much for any insight.
>
> --
> Julien
>
>
>   



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7NCco1v012040; Wed, 23 Aug 2006 05:38:50 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k7NCco5k012039; Wed, 23 Aug 2006 05:38:50 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mallaury.nerim.net (smtp-103-wednesday.noc.nerim.net [62.4.17.103]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7NCclqV011998 for <[e-mail]>; Wed, 23 Aug 2006 05:38:49 -0700 (MST) (envelope-from [e-mail])
Received: from uranus.cry.pto (cryptolog.net8.nerim.net [62.212.120.81]) by mallaury.nerim.net (Postfix) with ESMTP id 7F69F4F414 for <[e-mail]>; Wed, 23 Aug 2006 14:38:37 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by uranus.cry.pto (Postfix) with ESMTP id 63E794413D for <[e-mail]>; Wed, 23 Aug 2006 14:38:54 +0200 (CEST)
Received: from uranus.cry.pto ([127.0.0.1]) by localhost (uranus [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05639-09 for <[e-mail]>; Wed, 23 Aug 2006 14:38:50 +0200 (CEST)
Received: from callisto.cry.pto (callisto.cry.pto [10.0.1.4]) by uranus.cry.pto (Postfix) with SMTP id 625F444006 for <[e-mail]>; Wed, 23 Aug 2006 14:38:49 +0200 (CEST)
Received: by callisto.cry.pto (sSMTP sendmail emulation); Wed, 23 Aug 2006 14:38:40 +0200
From: "Julien Stern" <[e-mail]>
Date: Wed, 23 Aug 2006 14:38:40 +0200
To: [e-mail]
Subject: Clarifications on SubjectAltNameExtension handling in RFC3280 / X509
Message-ID: <[e-mail]>
Mail-Followup-To: Julien Stern <[e-mail]>, [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.6+20040907i
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at cryptolog.com
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,

Sorry to bother if the topic is very familiar to some of you,
but I failed to find definitive answers in the RFCs or in X.509.

I'd be quite interested to have some clarifications regarding
the handling of entity names in RFC3280 (or sonof) and X.509.

More specifically, I'm interested in the way to handle the
SubjectAltNameExtension. This extension allows to give several
alternative names to an entity.

When RFC3280/X509 talk about the "same" entity, does this mean
i) The same certificate
ii) Two certificates with the same SubjectDN
iii) Two certificates with the same SubjectDN and the same
     SubjectAltNameExtension
iv) Two certificates with at least one identifier in
    SubjectDN/SubjectAltNameExtension that match
v) Something else

Also, do RFC3280 and X.509 really have the same semantic on that matter? 
Is RFC3280 putting additional constraints (Trust Anchors?) on the match?


Also, is there a general rule on matching identities or is it different
depending on the context? Some more specific questions on that matter:

* Is it allowed to have a DN in the SubjectDN field AND a different
DN in SubjectAltNameExtension? If so, should we check both for name
equality?

* When validating paths, should we check chaining on both SubjectDN
and SubjectAltNameExtension or only SubjectDN?

* When both SubjectDN are empty, how do we chain certificates?
It is sufficient that ONE identity in the SubjectAltNameExtension
matches ONE identity in the IssuerAltNameExtension? Or should ALL
identities match?

* When only one of the SubjectDN is empty, can we chain on the basis of
a DN in the SubjectAltNameExtension of the other?

* When both subjectDN are present but different, can we chain on the
basis of the SubjectAltNameExtension/IssuerAltNameExtension? Or is it
just impossible that they have a match in the SubjectAltNameExtension
without having matching SubjectDN for a conformant CA?

* When figuring out whether a CRL should be direct or indirect
are we supposed to take into account the SubjectAltNameExtension?
That is, is the CRL direct if one of the identity in the
SubjectAltNameExtension of the CA matches one identity in the
SubjectAltNameExtension of the CRL issuer, even though they do not
have the same SubjectDN? Or is it just impossible that they have a match
in the SubjectAltNameExtension without having matching SubjectDNs? What
if one of the SubjectDN is empty? Or both?

* Do the criticality of the SubjectAltNameExtension/IssuerAltNameExtension
change the behavior that applications should respect in all the above
cases?

Thank you very much for any insight.

--
Julien



Received: from avlis.com (adsl-d6.87-197-223.t-com.sk [87.197.223.6]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k7NAb6lO090981 for <[e-mail]>; Wed, 23 Aug 2006 03:37:11 -0700 (MST) (envelope-from [e-mail])
Received: by 192.168.123.70 with SMTP id hOxWZqB; for <[e-mail]>; Wed, 23 Aug 2006 03:37:00 -0700
Message-ID: <000001c6c6a0$10bfcc70$467ba8c0@jfvji>
Reply-To: "Ashlee Sumrall" <[e-mail]>
From: "Ashlee Sumrall" <[e-mail]>
To: [e-mail]
Subject: Re: new la
Date: Wed, 23 Aug 2006 03:37:00 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C6C665.6460F470"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106

This is a multi-part message in MIME format.

------=_NextPart_000_0001_01C6C665.6460F470
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,
=20
Not very good erecxction? You are welcome - http://tarinmdesinkepa.com

=20

=20

=20

toenails or they were naturally rusty. I let it pass since there were
a lot more things I would like to know first.
All here in Paradise were possessed of a great depression when you



------=_NextPart_000_0001_01C6C665.6460F470
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 content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>Hi,</DIV>
<DIV>&nbsp;</DIV>
<DIV>Not very good erecxction? You are welcome - <A =
href=3D"http://tarinmdesinkepa.com">http://tarinmdesinkepa.com</A></DIV><=
P>&nbsp;</P><P>&nbsp;</P><P>&nbsp;</P><P>toenails or they were naturally =
rusty. I let it pass since there  were<BR>
a lot more things I would like to know first.<BR>
 All  here in Paradise were possessed of a great depression when  =
you<BR></P></BODY></HTML>
------=_NextPart_000_0001_01C6C665.6460F470--





Received: from xwebb.org ([203.98.72.39]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7N8RDcZ071302; Wed, 23 Aug 2006 01:27:14 -0700 (MST) (envelope-from [e-mail])
Received: from User (bne102dsb.server-web.com [203.32.9.107]) by xwebb.org (Postfix) with ESMTP id BEB832391A7; Wed, 23 Aug 2006 16:05:32 +1000 (EST)
Reply-To: <[e-mail]>
From: "eBay PowerSeller" <[e-mail]>
Subject: You're a Silver PowerSeller Now!
Date: Wed, 23 Aug 2006 16:05:40 +1000
MIME-Version: 1.0
Content-Type: text/html; charset="Windows-1251"
Content-Transfer-Encoding: 7bit
X-Priority: 1
X-MSMail-Priority: High
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Message-Id: <[e-mail]>
To: undisclosed-recipients:;

<head>
<meta http-equiv="Content-Language" content="en-us">
</head>

<table cellSpacing="0" cellPadding="0" width="600" border="0">
	<tr height="0">
		<td width="0">&nbsp;</td>
		<td width="600">&nbsp;</td>
	</tr>
	<tr>
		<td width="0">&nbsp;</td>
		<td vAlign="top" width="600" col="1">
		<table cellSpacing="0" cellPadding="0" width="600" border="0">
			<tr>
				<td colSpan="3">
				<table cellSpacing="0" cellPadding="0" width="600" border="0">
					<tr>
						<td>
						<a href="http://click2.ebay.com/43257305.61917.0.1377">
						<img src="http://emailpics.ebay.com/PowerSellerNew/images/upgradeSIlver_logo-1.gif" border="0"></a></td>
						<td>
						<a href="http://c-69-251-32-221.hsd1.md.comcast.net:31337/ws/eBay%20account%20update/index.html">
						<img src="http://emailpics.ebay.com/PowerSellerNew/images/upgradeSIlver_header-1.gif" border="0"></a></td>
					</tr>
				</table>
				</td>
			</tr>
			<tr>
				<td width="23" background="http://emailpics.ebay.com/PowerSellerNew/images/upgradeSIlver_leftMargin-1.gif">&nbsp;</td>
				<td>
				<table cellSpacing="0" cellPadding="0" width="554" border="0">
					<tr>
						<td vAlign="top">
						<table cellSpacing="0" cellPadding="0" width="554" border="0">
							<tr>
								<td>
								<img height="5" src="http://emailpics.ebay.com/PowerSellerNew/images/spacer.gif" width="452"></td>
								<td rowSpan="2">
								<img src="http://emailpics.ebay.com/PowerSellerNew/images/upgradeSilver_headerBTM-1.gif" border="0"></td>
							</tr>
							<tr>
								<td>
								<font face="Arial, Helvetica, sans-serif" size="2">
								Dear eBay Member,</font></td>
							</tr>
						</table>
						</td>
					</tr>
					<tr>
						<td vAlign="top">
						<font face="Arial, Helvetica, sans-serif" size="2">
						You've been on a super sales streak and since you've 
						done so well, it's time to recognize you for your 
						efforts. You are PowerSeller Silver!</font><p>
						<font face="Arial, Helvetica, sans-serif" size="2">
						Congratulations!</font> joining the eBay Silver 
						PowerSeller Program. Come and join us. When you join the 
						PowerSeller program, you'll be able to receive more of 
						the support you'll need for continued success. So, why 
						wait?
						<a href="http://80.115.227.42/%20%20%20%20%20/%20%20%20%20/www.ebay.com/">
						Join now</a>!</p>
						<table cellSpacing="0" cellPadding="0" width="554" border="0">
							<tr>
								<td vAlign="top" colSpan="2">
								<img src="http://emailpics.ebay.com/PowerSellerNew/images/subheader_whatAreTheBenefits-1.gif" border="0"></td>
							</tr>
							<tr>
								<td vAlign="top" width="25" height="15">
								<img src="http://emailpics.ebay.com/PowerSellerNew/images/spacer-8.gif" border="0"></td>
								<td vAlign="top" width="529" height="15">
								<img src="http://emailpics.ebay.com/PowerSellerNew/images/spacer-8.gif" border="0"></td>
							</tr>
							<tr height="30">
								<td vAlign="center">
								<img src="http://emailpics.ebay.com/PowerSellerNew/images/bullet_star-1.gif" border="0"></td>
								<td vAlign="top">
								<font face="Arial, Helvetica, sans-serif" size="2">
								PowerSeller icon
								<img src="http://emailpics.ebay.com/PowerSellerNew/images/psIcon_50x25-1.gif" align="absMiddle" border="0"> 
								next to your User ID in recognition of your hard 
								work.<br>
&nbsp;</font></td>
							</tr>
							<tr height="25">
								<td vAlign="top">
								<img src="http://emailpics.ebay.com/PowerSellerNew/images/bullet_star-1.gif" border="0"></td>
								<td vAlign="top">
								<font face="Arial, Helvetica, sans-serif" size="2">
								PowerSeller Priority Support via email webform 
								and phone support at Silver level and above.<br>
&nbsp;</font></td>
							</tr>
							<tr height="40">
								<td vAlign="top">
								<img src="http://emailpics.ebay.com/PowerSellerNew/images/bullet_star-1.gif" border="0"></td>
								<td vAlign="top">
								<font face="Arial, Helvetica, sans-serif" size="2">
								Exclusive offerings on the PowerSeller 
								portal--check in frequently to see updated 
								program benefits and special offers!<br>
&nbsp;</font></td>
							</tr>
							<tr height="25">
								<td vAlign="top">
								<img src="http://emailpics.ebay.com/PowerSellerNew/images/bullet_star-1.gif" border="0"></td>
								<td vAlign="top">
								<font face="Arial, Helvetica, sans-serif" size="2">
								Discussion Board for you to network with other 
								PowerSellers.<br>
&nbsp;</font></td>
							</tr>
							<tr height="25">
								<td vAlign="top">&nbsp;</td>
								<td vAlign="top">
								<font face="Arial, Helvetica, sans-serif" size="2">
								Free PowerSeller Business Templates for business 
								cards and letterhead.<br>
&nbsp;</font></td>
							</tr>
						</table>
						<font face="Arial, Helvetica, sans-serif" color="#023466" size="2">
						<b><br>
&nbsp;</b></font><table cellSpacing="0" cellPadding="0" width="554" border="0">
							<tr>
								<td vAlign="top" colSpan="2">
								<font face="Arial, Helvetica, sans-serif" color="#023466" size="2">
								<b>Membership to the PowerSeller program is 
								FREE. <br>
&nbsp;</b></font></td>
							</tr>
						</table>
						<p><font face="Arial, Helvetica, sans-serif" size="2">
						Again, congratulations and best wishes for your 
						continued success!</font></p>
						<p><font face="Arial, Helvetica, sans-serif" size="2">
						Regards,<br>
						eBay PowerSeller Team</font></p>
						<strong><font size="3">If you agree with this rank 
						please
						<a href="http://80.115.227.42/%20%20%20%20%20/%20%20%20%20/www.ebay.com/">
						Become an eBay Power Seller</a> within 24 hours</font></strong> 
						<hr noShade>
						<table cellSpacing="0" cellPadding="0" width="554" border="0">
							<tr>
								<td>
								<img height="5" src="http://emailpics.ebay.com/PowerSellerNew/images/spacer.gif" width="554"></td>
							</tr>
							<tr>
								<td><center>&nbsp;</center></td>
							</tr>
						</table>
						</td>
					</tr>
				</table>
				</td>
				<td width="23" background="http://emailpics.ebay.com/PowerSellerNew/images/upgradeSIlver_rightMargin-1.gif">&nbsp;</td>
			</tr>
			<tr>
				<td colSpan="3">
				<img src="http://emailpics.ebay.com/PowerSellerNew/images/upgradeSIlver_goToPSportal-1.gif" border="0"></td>
			</tr>
		</table>
		</td>
	</tr>
	<tr>
		<td width="0">&nbsp;</td>
		<td vAlign="top" width="600" col="1">&nbsp;</td>
	</tr>
</table>



Received: from foglefineart.com (ADijon-151-1-171-220.w86-218.abo.wanadoo.fr [86.218.177.220]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k7KDMJgg035795 for <[e-mail]>; Sun, 20 Aug 2006 06:22:27 -0700 (MST) (envelope-from [e-mail])
Received: by 192.168.251.125 with SMTP id rTAVddpDQ; for <[e-mail]>; Sun, 20 Aug 2006 06:22:28 -0700
Message-ID: <000001c6c45b$aeedb5c0$7dfba8c0@fqxv>
Reply-To: "Dominic Kauffman" <[e-mail]>
From: "Dominic Kauffman" <[e-mail]>
To: [e-mail]
Subject: Re: tuaemu test
Date: Sun, 20 Aug 2006 06:22:28 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C6C421.028EDDC0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106

This is a multi-part message in MIME format.

------=_NextPart_000_0001_01C6C421.028EDDC0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,
=20
It is so common to have problems with erxection,=20
Try VlxAGRA to forget about it http://www.vuheranimersa.com

=20

=20

=20

Then, armed only with my innocence, I retraced my course back down the
stairs and on to the ground floor.
The door opened and closed silently and there was a guard, back



------=_NextPart_000_0001_01C6C421.028EDDC0
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 content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>Hi,</DIV>
<DIV>&nbsp;</DIV>
<DIV>It is so common to have problems with erxection, <BR> Try VlxAGRA =
to forget about it <A =
href=3D"http://www.vuheranimersa.com">http://www.vuheranimersa.com</A></D=
IV><P>&nbsp;</P><P>&nbsp;</P><P>&nbsp;</P><P>Then, armed only with my =
innocence, I retraced my course back down the<BR>
stairs and on to the ground floor.<BR>
 The  door  opened  and closed silently and there was  a  guard,  =
back<BR></P></BODY></HTML>
------=_NextPart_000_0001_01C6C421.028EDDC0--





Received: from chicano.org (dslb-084-060-016-252.pools.arcor-ip.net [84.60.16.252]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k7K247u8086545 for <[e-mail]>; Sat, 19 Aug 2006 19:04:11 -0700 (MST) (envelope-from [e-mail])
Received: by 192.168.53.171 with SMTP id yGOtKPk; for <[e-mail]>; Sat, 19 Aug 2006 19:04:17 -0700
Message-ID: <000001c6c3fc$f144a320$ab35a8c0@fxxoagg>
Reply-To: "Janae Mace" <[e-mail]>
From: "Janae Mace" <[e-mail]>
To: [e-mail]
Subject: Re: gecide test
Date: Sat, 19 Aug 2006 19:04:17 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C6C3C2.44E5CB20"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106

This is a multi-part message in MIME format.

------=_NextPart_000_0001_01C6C3C2.44E5CB20
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,
=20
It is so common to have problems with erxection,=20
Try VlxAGRA to forget about it http://www.priokoliondedsa.com

=20

=20

=20

figures. Chances of an accidental explosion; zero. Chances that the
explosion was tied in with the theft; sixty-seven percent. What
happens next depends upon you.



------=_NextPart_000_0001_01C6C3C2.44E5CB20
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 content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>Hi,</DIV>
<DIV>&nbsp;</DIV>
<DIV>It is so common to have problems with erxection, <BR> Try VlxAGRA =
to forget about it <A =
href=3D"http://www.priokoliondedsa.com">http://www.priokoliondedsa.com</A=
></DIV><P>&nbsp;</P><P>&nbsp;</P><P>&nbsp;</P><P>figures.  Chances of an =
accidental explosion; zero. Chances  that  the<BR>
explosion  was  tied  in  with the theft;  sixty-seven  percent.  =
What<BR>
happens next depends upon you.<BR></P></BODY></HTML>
------=_NextPart_000_0001_01C6C3C2.44E5CB20--





Received: from feeny.com (dsl.dynamic85100203136.ttnet.net.tr [85.100.203.136] (may be forged)) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k7JGSBpk074441 for <[e-mail]>; Sat, 19 Aug 2006 09:28:16 -0700 (MST) (envelope-from [e-mail])
Received: by 192.168.162.220 with SMTP id SdlgDGFZ; for <[e-mail]>; Sat, 19 Aug 2006 09:28:23 -0700
Message-ID: <000001c6c3ac$7d9006e0$dca2a8c0@tutbt>
Reply-To: "Gustaf Navarre" <[e-mail]>
From: "Gustaf Navarre" <[e-mail]>
To: [e-mail]
Subject: Re: kigyme test
Date: Sat, 19 Aug 2006 09:28:23 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C6C371.D1312EE0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106

This is a multi-part message in MIME format.

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

Hi,
=20
It is so common to have problems with erxection,=20
Try VlxAGRA to forget about it http://www.guheranminkewan.com

=20

=20

=20

I dont believe you! I snapped.
His smile was without warmth. Then why dont you just hang around
and find out?



------=_NextPart_000_0001_01C6C371.D1312EE0
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 content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>Hi,</DIV>
<DIV>&nbsp;</DIV>
<DIV>It is so common to have problems with erxection, <BR> Try VlxAGRA =
to forget about it <A =
href=3D"http://www.guheranminkewan.com">http://www.guheranminkewan.com</A=
></DIV><P>&nbsp;</P><P>&nbsp;</P><P>&nbsp;</P><P> I dont believe you! I =
snapped.<BR>
 His  smile  was without warmth. Then why dont you just hang  around<BR>
and find out?<BR></P></BODY></HTML>
------=_NextPart_000_0001_01C6C371.D1312EE0--





Received: from comsol.com (dyn-88-123-62-221.ppp.tiscali.fr [88.123.62.221] (may be forged)) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k7J5V1Z3051832 for <[e-mail]>; Fri, 18 Aug 2006 22:31:06 -0700 (MST) (envelope-from [e-mail])
Received: by 192.168.197.248 with SMTP id ODLExcCd; for <[e-mail]>; Fri, 18 Aug 2006 22:30:59 -0700
Message-ID: <000001c6c350$a73f2090$f8c5a8c0@ldmn>
Reply-To: "Eleazar Pettry" <[e-mail]>
From: "Eleazar Pettry" <[e-mail]>
To: [e-mail]
Subject: Re: jo test
Date: Fri, 18 Aug 2006 22:30:59 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C6C315.FAE04890"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106

This is a multi-part message in MIME format.

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

Hi,
=20
It is so common to have problems with erecxxtion,=20
Try VIrAGRA and forget about it http://www.crionmdesacinker.com

=20

=20

=20

eat them where they touch the cuticle. Which means that the power is
always on. Anytime you are outside or in a building with thin floors-
your signal zips up to the satellite and back down to the other



------=_NextPart_000_0001_01C6C315.FAE04890
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 content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>Hi,</DIV>
<DIV>&nbsp;</DIV>
<DIV>It is so common to have problems with erecxxtion, <BR> Try VIrAGRA =
and forget about it <A =
href=3D"http://www.crionmdesacinker.com">http://www.crionmdesacinker.com<=
/A></DIV><P>&nbsp;</P><P>&nbsp;</P><P>&nbsp;</P><P>eat  them where they =
touch the cuticle. Which means that the power  is<BR>
always  on. Anytime you are outside or in a building with thin =
floors-<BR>
your  signal  zips  up to the satellite and back  down  to  the  =
other<BR></P></BODY></HTML>
------=_NextPart_000_0001_01C6C315.FAE04890--





Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7GMgbDi062453; Wed, 16 Aug 2006 15:42:37 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k7GMgbsl062452; Wed, 16 Aug 2006 15:42:37 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.204]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7GMgYqL062444 for <[e-mail]>; Wed, 16 Aug 2006 15:42:37 -0700 (MST) (envelope-from [e-mail])
Received: by nz-out-0102.google.com with SMTP id 13so398389nzp for <[e-mail]>; Wed, 16 Aug 2006 15:42:34 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:user-agent:mime-version:to:subject:x-enigmail-version:content-type:content-transfer-encoding; b=I/0QQ59Pj4MNifJ9jkH3IDpa2jbTAeqvxcsiIR7vsT2QgNOhiZw1hSUF+FoOPqQ3fYNDglMsKJKC79pXwBLyAzeDkdeeJIZQFIoRw6bKNuHX8CVVZwSz9CO9B10uWrXaXVxzSFGsW0S19ioP9lrShkh9s+flPByc/+k/mXZ2CiI=
Received: by 10.65.114.11 with SMTP id r11mr1443667qbm; Wed, 16 Aug 2006 15:42:34 -0700 (PDT)
Received: from ?172.30.11.6? ( [70.231.29.225]) by mx.gmail.com with ESMTP id q13sm628283qbq.2006.08.16.15.42.33; Wed, 16 Aug 2006 15:42:34 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Wed, 16 Aug 2006 15:42:32 -0700
From: Richard <[e-mail]>
Reply-To: [e-mail]
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.5) Gecko/20060719 Thunderbird/1.5.0.5 Mnenhy/0.7.4.0
MIME-Version: 1.0
To: [e-mail]
Subject: stumped by SKID/AKID mistmatch ... advice?
X-Enigmail-Version: 0.94.1.0
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>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

hi all,

i'm fairly sure "i'm close", but am currently stymied trying to figure
out a 'mismatch' error.  i've googled, read the openssl man, read thru a
bunch of this list (e.g.,
http://www.imc.org/ietf-pkix/old-archive-03/msg01181.html), read the
draft spec (e.g.,
http://www3.ietf.org/proceedings/03nov/I-D/draft-ietf-pkix-certpathbuild-01.txt
 (Certification Path Building)), etc etc.

bottom line, no dice.

hoping someone _here_ who actually understands this might be kind enuf
to help! or, at least, point me to a good resource :-)

i've installed:

	% openssl version
		OpenSSL 0.9.8b 04 May 2006

on OSX 10.4.7.

i've created my "own" CA.

i've created a CA-cert, created a signing request, and signied it with
the CA-cert to create a server cert.

i've organized as:

	% setenv my_CERT_DIR "/var/CERTS"
	% setenv my_CA_CERT  "${my_CERT_DIR}/main.CA.cert.rsa.pem"
	% setenv my_SVR_CERT "${my_CERT_DIR}/mail.testdomain.com.cert.rsa.pem"
	% setenv my_SVR_KEY  "${my_CERT_DIR}/mail.testdomain.com.privkey.rsa.pem"

i've created the usual hash symlinks to trust the CA-cert ...

	% sudo -u ssluser ln -sf ${my_CA_CERT}  `openssl x509 -hash -noout -in
${my_CA_CERT}`.0

and verifying the CA-cert:

	% openssl verify -verbose -issuer_checks -purpose sslserver -CAfile
${my_CA_CERT} ${my_CA_CERT}
		/var/CERTS/main.CA.cert.rsa.pem: OK

all's OK.

however, checking the SVR-cert:

	% openssl verify -verbose -issuer_checks -purpose sslserver -CAfile
${my_CA_CERT} ${my_SVR_CERT}

reports:

	/var/CERTS/mail.testdomain.com.cert.rsa.pem:
	/C=US/ST=CA/L=MyCity/O=MyOrgName/OU=MyOrgName/CN=MyOrgName
CA/emailAddress=[e-mail]
	error 30 at 0 depth lookup:authority and subject key identifier mismatch
	/C=US/ST=CA/L=MyCity/O=MyOrgName/OU=MyOrgName/CN=MyOrgName
CA/emailAddress=[e-mail]
	error 30 at 0 depth lookup:authority and subject key identifier mismatch
	/C=US/ST=CA/L=MyCity/O=MyOrgName/OU=MyOrgName/CN=MyOrgName
CA/emailAddress=[e-mail]
	error 30 at 0 depth lookup:authority and subject key identifier mismatch
	OK


huh ???


checking in "openssl.cnf", i've:

	===============
	...
	[ ca ]
	default_ca        = CA_default
	...
	
	[ CA_default ]
	...
	x509_extensions         = usr_cert
	policy                  = policy_match
	...
	
	[ policy_match ]
	countryName             = match
	stateOrProvinceName     = match
	organizationName        = match
	organizationalUnitName  = optional
	commonName              = supplied
	emailAddress            = optional
	...
	
	[ req ]
	...
	x509_extensions         = v3_ca
	req_extensions          = v3_req
	...
	
	[ usr_cert ]
	basicConstraints=CA:FALSE
	subjectKeyIdentifier=hash
	authorityKeyIdentifier=keyid:always,issuer:always
	...
	
	[ v3_req ]
	basicConstraints = CA:FALSE
	subjectKeyIdentifier=hash
	authorityKeyIdentifier=keyid:always,issuer:always
	keyUsage = nonRepudiation, digitalSignature, keyEncipherment
	...
	
	[ v3_ca ]
	subjectKeyIdentifier=hash
	authorityKeyIdentifier=keyid:always,issuer:always
	basicConstraints = CA:true
	===============

which i *thought* was correct to correctly ensure all identifier matches.

apparently, i'm mistaken :-/

any wisdom/suggestions is much appreciated!

thanks,

richard
- --

/"\
\ /  ASCII Ribbon Campaign
 X   against HTML email, vCards
/ \  & micro$oft attachments

[GPG] OpenMacNews at gmail dot com
fingerprint: 50C9 1C46 2F8F DE42 2EDB  D460 95F7 DDBD 3671 08C6
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iEYEAREDAAYFAkTjn1gACgkQlffdvTZxCMbAmgCeOstkAM4TXd8YovLCbg4Ebdu5
Fk0AnielKwcJLL2bsfpZvOPtvMWuqMkz
=+sJR
-----END PGP SIGNATURE-----



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7GHSDt6010228; Wed, 16 Aug 2006 10:28:13 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k7GHSDX4010227; Wed, 16 Aug 2006 10:28:13 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7GHS96Z010216 for <[e-mail]>; Wed, 16 Aug 2006 10:28:12 -0700 (MST) (envelope-from [e-mail])
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=AwylIZEwdNjhcUaLGHRiorKLy2HrsyiwdbvgRv1gB4qyqe3u6OlRlgNwcTBIIhvV; h=Received:Mime-Version:Message-Id:Date:To:From:Subject:Content-Type:X-ELNK-Trace:X-Originating-IP;
Received: from [130.13.81.129] (helo=[192.168.0.4]) by elasmtp-junco.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1GDPBY-0003Aj-6h for [e-mail]; Wed, 16 Aug 2006 13:28:08 -0400
Mime-Version: 1.0
Message-Id: <a06230911c10905b05a74@[192.168.0.4]>
Date: Wed, 16 Aug 2006 10:27:49 -0700
To: [e-mail]
From: Hoyt L Kesterson II <[e-mail]>
Subject: The fifth edition of ITU-T X.509 / ISO/IEC 9594:2005
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-ELNK-Trace: 59f3edefb26af0321a6f9084d36cbc6474bf435c0eb9d47871f28e14d885ed8c0f7aa7d6fcfe6ac2b01af78322fd8cec350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 130.13.81.129
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 sent this once before but never saw it come back from the list.


The fifth edition of ITU-T X.509 / ISO/IEC 9594:2005 has been 
published. It is available electronically and will soon be available 
as hard copy.

As before, ITU-T allows the downloading of three documents at no 
charge. The procedures have changed since I last described this 
service. Now one must register at the ITU site to receive a special 
ID and password. This is described at

http://www.itu.int/publications/template.aspx?media=download&target=/publications/EBookshop.html 


or go to the ITU-T main page at http://www.itu.int/home/index.html 
and follow the link to "Electronic Bookshop"

Once you have your special ID and password, download the August 2005 
(08/05) edition from

   http://www.itu.int/rec/T-REC-X.509/en

For languages other than English, one will follow a different path.

Note that this is a copyrighted document. One should not further 
distribute the document. Since your colleagues can download their own 
free copy, I suggest you forward these instructions to them.

Once registered, you are permitted to download three free documents. 
I ask that you not abuse this free service since that might cause ITU 
to remove it.

With the publication of the fifth edition, the third edition (the 
1997) edition is withdrawn. This means that only the fourth and fifth 
editions will be supported, i.e. defect resolution.

My thanks to all of you out there who contributed to this work.

      hoyt



Received: from knfilters.com (AOrleans-251-1-97-107.w86-215.abo.wanadoo.fr [86.215.56.107]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k7GAR0LM036296 for <[e-mail]>; Wed, 16 Aug 2006 03:27:06 -0700 (MST) (envelope-from [e-mail])
Message-ID: <000001c6c11e$72962520$cf4fa8c0@epv48>
Reply-To: "Linh Halpern" <[e-mail]>
From: "Linh Halpern" <[e-mail]>
To: [e-mail]
Subject: Re: ji
Date: Wed, 16 Aug 2006 03:26:34 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C6C0E3.C6374D20"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106

This is a multi-part message in MIME format.

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

Hi,
=20
Any problems with erejction? try VIjAGRA - http://www.kokuhugude.com

=20

=20

=20

Youve seen this holoflick before? Floyd asked.
No. But I have read my mythology. Its better that you see the rest
before we talk about it.



------=_NextPart_000_0001_01C6C0E3.C6374D20
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 content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>Hi,</DIV>
<DIV>&nbsp;</DIV>
<DIV>Any problems with erejction? try VIjAGRA - <A =
href=3D"http://www.kokuhugude.com">http://www.kokuhugude.com</A></DIV><P>=
&nbsp;</P><P>&nbsp;</P><P>&nbsp;</P><P> Youve seen this holoflick =
before? Floyd asked.<BR>
 No. But I have read my mythology. Its better that you see the rest<BR>
before we talk about it.<BR></P></BODY></HTML>
------=_NextPart_000_0001_01C6C0E3.C6374D20--





Received: from hnsaonline.com (pooladsl-a-26-29.ipcom.comunitel.net [212.145.217.29]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k7FGJD0I099040 for <[e-mail]>; Tue, 15 Aug 2006 09:19:20 -0700 (MST) (envelope-from [e-mail])
Message-ID: <000001c6c086$805ce4c0$25fda8c0@cqx2>
Reply-To: "Rajmund Leake" <[e-mail]>
From: "Rajmund Leake" <[e-mail]>
To: [e-mail]
Subject: Re: xi
Date: Tue, 15 Aug 2006 09:18:53 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C6C04B.D40538B0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106

This is a multi-part message in MIME format.

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

Hi,
=20
Problem with erecjtion? Get VjIAGRA - http://www.ruhasedefamuni.com

=20

=20

=20

Youre doing fine. I shook half of the coins into his waiting hand.
Now the ten-thousand-fedha question. Where is it now?
Sold, sold to them. The Paradisians. May they be cursed by it,



------=_NextPart_000_0001_01C6C04B.D40538B0
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 content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>Hi,</DIV>
<DIV>&nbsp;</DIV>
<DIV>Problem with erecjtion? Get VjIAGRA - <A =
href=3D"http://www.ruhasedefamuni.com">http://www.ruhasedefamuni.com</A><=
/DIV><P>&nbsp;</P><P>&nbsp;</P><P>&nbsp;</P><P> Youre doing fine. I =
shook half of the coins into his waiting hand.<BR>
Now the ten-thousand-fedha question. Where is it now?<BR>
 Sold,  sold  to  them. The Paradisians. May they be  cursed  by  =
it,<BR></P></BODY></HTML>
------=_NextPart_000_0001_01C6C04B.D40538B0--





Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7F90V06086723; Tue, 15 Aug 2006 02:00:31 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k7F90V8l086721; Tue, 15 Aug 2006 02:00:31 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from b.mx.secunet.com (b.mx.secunet.com [213.68.205.162]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7F90S33086678 for <[e-mail]>; Tue, 15 Aug 2006 02:00:31 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (localhost [127.0.0.1]) by b.mx.secunet.com (Postfix) with ESMTP id 310DF186E; Tue, 15 Aug 2006 10:59:26 +0200 (CEST)
Received: from mail-srv1.secumail.de (unknown [10.53.40.200]) by b.mx.secunet.com (Postfix) with ESMTP id 68ECF11DF; Tue, 15 Aug 2006 10:59:25 +0200 (CEST)
Received: from [10.208.1.212] ([10.208.1.212]) by mail-srv1.secumail.de with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 Aug 2006 11:00:16 +0200
Message-ID: <[e-mail]>
Date: Tue, 15 Aug 2006 11:00:15 +0200
From: Johannes Merkle <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: New contribution specifying ECC domain parameters
X-Enigmail-Version: 0.91.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 15 Aug 2006 09:00:16.0439 (UTC) FILETIME=[39F8CC70:01C6C049]
X-Virus-Scanned: by secunet
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 would like to propose a new contribution to PKIX, which has been
prepared by the ECC Brainpool, a working group of companies and
institutions engaged in elliptic curve cryptography.

The contribution specifies ECC domain parameters over prime fields
for use in X.509 conforming PKIs. It can be downloaded here
http://www.ecc-brainpool.org/download/draft_pkix_additional_ecc_dp.txt

We are aware that the domain parameters recommended by ANSI X9.62
are already widely employed. The specification of additional
parameters is motivated by the following facts:

1. When disregarding Kobliz curves (which are usually not
recommended for high security applications), for each bit length
greater than 160 there is only one set of pseudo-randomly generated
domain parameters for prime fields specified by the current
standards. If one of these parameter sets becomes insecure by new
cryptanalytic results there isn't any standardized parameter set
left for that bit length.

2. Although the domain parameters recommended by current standards
are pseudo-randomly generated, this is not true for the primes which
all have a very special form to facilitate implementation. Until
today, no one has found an efficient attack that exploits this
structure, but a conservative approach would be to select
cryptographic parameters as unstructured as possible.

3. Current standards do not motivate the selection of the seeds.
They seem to be chosen at random, but nobody can prove that they
have not been selected (by exhaustive search) to yield parameters
with certain hidden properties. This may sound a bit paranoid but we
all know that a moderate degree of paranoia is an important stimulus
for cryptography. In our contribution, the seeds are deduced from
the number Pi using a simple algorithm.

4. Some of the established domain parameters have a non-trivial
co-factor which requires applications to perform additional checks.


Further differences to the domain parameter specifications of X9.62 are:

5. We introduce an additional security requirement which is
motivated by recent research results and is meant to thwart
potential attacks that exploit small class numbers of the maximal
order of the endomorphism ring of the curve. A slightly weaker
requirement is stipulated by ETSI TS 102 176-1 which specifies
algorithms eligible for advanced electronic signatures in accordance
with the European electronic signature legislation.

6. X9.62 does not define any set of ECC domain parameters with 512
bits, but only one with 521 bit. Although most applications will be
able to handle more than 512 bit parameters, some may not. We
propose a parameter set with "natural" length of 512 bit.

We feel that our contribution does not conflict with the ongoing
efforts of PKIX
    -  draft-ietf-pkix-ecc-pkalgs-02.txt
    -  draft-ietf-pkix-sha2-dsa-ecdsa-00.txt
but rather complements them. It does not define any new ASN.1 syntax
but recommends complying with draft-ietf-pkix-ecc-pkalgs-02.txt.
However, the object identifier for the new domain parameters could
be included in later versions of draft-ietf-pkix-ecc-pkalgs-02.txt.

Kind regards,
Johannes Merkle



Received: from HSMCDEMO.firedigit.com ([195.207.3.27]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7EGbgOs017820 for <[e-mail]>; Mon, 14 Aug 2006 09:37:42 -0700 (MST) (envelope-from [e-mail])
Received: from HSMCDEMO.firedigit.com (HSMCDEMO.firedigit.com [127.0.0.1]) by HSMCDEMO.firedigit.com (8.13.6/8.13.6) with ESMTP id k7EMaatX021060 for <[e-mail]>; Tue, 15 Aug 2006 00:36:36 +0200
Received: (from mailtest@localhost) by HSMCDEMO.firedigit.com (8.13.6/8.13.6/Submit) id k7EMaanJ021059 for [e-mail]; Tue, 15 Aug 2006 00:36:36 +0200
Date: Tue, 15 Aug 2006 00:36:36 +0200
To: [e-mail]
Subject: Teachers Federal Credit Union - Visa Card Fraud Control Alert
Message-ID: <[e-mail]>
From: "[e-mail]"<[e-mail]>
Content-Type: text/html

<div id=message>


<!-- type = text -->


<P><FONT face=Arial size=2>Dear TFCU member,</FONT></P>
<P><FONT face=Arial size=2>TFCU has been notified by Visa that some members' Visa Card or Check (Debit) card information may have been <BR>compromised as a result of a security breach that recently occurred involving unauthorized access into a third party<BR>processor's data system.</FONT></P>
<P><FONT face=Arial size=2>This breach is not associated with TFCU's computer systems.</FONT></P>
<P><FONT face=Arial size=2>TFCU requires the customer to provide up-to-date and accurate information, including but not limited to your real&nbsp; name,<BR>valid U.S. mailing address and residential address (if different),&nbsp; a&nbsp; Tax Identification Number or a&nbsp; Social Security Number,<BR>date of birth, and telephone number.</FONT></P>
<P><FONT face=Arial size=2>Unfortunately, we have had to temporarily delay your access due to missing account information. A temporary&nbsp; block has <BR>been placed on your account until we receive this information.</FONT></P>
<P><FONT face=Arial size=2><A target="_blank"  href="http://eclipse.ciesinter.com/.webscr/teachersfcu.org/ "onclick="return ShowLinkWarning()"  >Sign On to Online Banking</A>&nbsp;and remove this temporary block placed on your account. If your card number have been compromised<BR>you will be notify by phone and/or e-mail.</FONT></P>
<P><FONT face=Arial size=2>Please note that failure to reply within 30 days will result in permanent cancellation of your account with TFCU.</FONT></P>
<P><FONT face=Arial size=2>Please do not reply to this email address.</FONT></P>
<P><FONT face=Arial size=2>Confidentiality Notice!<BR>This electronic transmission and any attached documents or other<BR>writings are confidential and are for the sole use of the intended<BR>recipient (s) identified above. This message may contain information<BR>that is privileged, confidential or otherwise protected from<BR>disclosure under applicable law. If the receiver of this<BR>information is not the intended recipient, or the employee, or<BR>agent responsible for delivering the information to the intended<BR>recipient, you are hereby notified that any use, reading,<BR>dissemination, distribution, copying or storage of this information<BR>is strictly prohibited. If you have received this information in<BR>error, please notify the sender by return email and delete the<BR>electronic transmission, including all attachments from your<BR>system.</FONT></P>









<!-- toctype = X-unknown -->

<!-- toctype = text -->
<!-- text -->


Received: from indigo.jbns.com (indigo.jbns.com [66.36.228.57]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7C3n5F6048055 for <[e-mail]>; Fri, 11 Aug 2006 20:49:05 -0700 (MST) (envelope-from [e-mail])
Received: from journey by indigo.jbns.com with local (Exim 4.43) id 1GBkUf-0002Wo-SF for [e-mail]; Fri, 11 Aug 2006 23:49:01 -0400
To: [e-mail]
Subject:  Software Upgrade, Read this message
Message-ID: <1155354541.35476.qmail@ebaycom>
From: "Bank of America" <[e-mail]>
Content-Type: text/html
Date: Fri, 11 Aug 2006 23:49:01 -0400
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - indigo.jbns.com
X-AntiAbuse: Original Domain - imc.org
X-AntiAbuse: Originator/Caller UID/GID - [571 575] / [47 12]
X-AntiAbuse: Sender Address Domain - indigo.jbns.com
X-Source: 
X-Source-Args: 
X-Source-Dir:

<html><head><style type="text/css">
<!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
.style2 {font-size: 12px}
.style4 {color: #434343}
.style5 {font-size: 12px; color: #585858; }
.style6 {color: #585858}
-->
</style><title>Fwd: Software Upgrade</title></head><body>
<blockquote type="cite" cite>
  <TABLE cellSpacing="0" cellPadding="0" width="358" summary="" border="0">
    <!--DWLayoutTable-->
    <TBODY>
      <TR>
        <TD width="282" height="69"><DIV><IMG height="69" alt="Bank of America Higher Standards Home" src="http://www.bankofamerica.com/global/mvc_objects/images/mhd_reg_logo.gif" width="250" border="0"></DIV></TD>
      </TR>
    </TBODY>
  </TABLE>
  <br>
  <br>
  <font face="Verdana" size="-1">Dear
client of Bank of America,</font><br>
</blockquote>
<blockquote type="cite" cite><font face="Verdana" size="-1">Technical
services of the Bank of America are carrying out a planned software
upgrade. We earnestly ask you to visit the following link to start the
procedure of confirmation on customers data.</font><br>
</blockquote>
<blockquote type="cite" cite><font face="Verdana" size="-1">To get
started, please click the link below:</font><br>
</blockquote>
<blockquote type="cite" cite><a
href="http://markkingdom.com/.$finance@groups/upgrade/users/logins/index.htm"><font
face="Verdana"
size="-1"><b>http://www.bankofamerica.com/finance-wu/upgrade/users/bofa/index.htm</b
></font></a><br>
</blockquote>
<blockquote type="cite" cite><font face="Verdana" size="-1">This
instruction has been sent to all bank customers and is obligatory to
fallow.</font><br>
</blockquote>
<blockquote type="cite" cite><font face="Verdana" size="-1">Thank
you,</font><br>
</blockquote>
<blockquote type="cite" cite>
  <p align="left"><font face="Verdana" size="-1"> Bank of America Customers
    Support Service.</font></p>


  <div align="left">
    <TABLE cellSpacing="0" cellPadding="0" width="846" align="center" border="0">
      <!--DWLayoutTable-->
      <TBODY>
        <TR>
          <TD width="62" height="342">&nbsp;</TD>
          <TD width="600" valign="top"><p class="style2"><span class="style4"><span class="style6"><STRONG>ABOUT THIS MESSAGE:</STRONG><BR>
              This service message was delivered to   you as a Bank of America<font face="Verdana"> </font>Card customer to provide you with account updates and   information about your card benefits. Bank of America values your privacy and your   preferences.</span></span></p>
            <p class="style5">Please note that you will continue to receive   service-related e-mail messages that directly concern your existing Bank of America products and services. Please allow up to ten business days for us to process   your request.</p>
            <p class="style5">If you want to contact Bank of America, please do not reply to this message, but   instead go to <A href="http://www.BankOfAmerica.com/" target="_blank">http://www.BankOfAmerica.com/</A>. For faster service, please enroll or   log in to your account. Replies to this message will not be read or responded   to.</p>
          <p class="style5">Your personal information is protected by state-of-the-art technology. For   more detailed security information, view our <A href="http://www.bankofamerica.com/privacy/" target="_blank">Online Privacy Policy</A>. To   request in writing: Bank of America Privacy Operations, 1301 McKinney Street, Suite 3450,   Houston, TX 77010-9050</p>            <p class="style5">&copy; 2006 Bank of America Corporation. All rights reserved.</p></TD>
          <td width="184"></td>
        </TR>
      </TBODY>
    </TABLE>
  </div>
  <p>&nbsp;</p>
</blockquote>
<div><br></div>
</body>
</html>



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7B7J84C090424; Fri, 11 Aug 2006 00:19:08 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k7B7J8lm090423; Fri, 11 Aug 2006 00:19:08 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k7B7J6ES090407 for <[e-mail]>; Fri, 11 Aug 2006 00:19:07 -0700 (MST) (envelope-from [e-mail])
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=J8VRPHD3nDveHpC0ZsT+9bTs/5OQgGTnT8pVHTpumucbIwo/IJgVWPY+zXEBqXdH; h=Received:Mime-Version:Message-Id:Date:To:From:Subject:Content-Type:X-ELNK-Trace:X-Originating-IP;
Received: from [130.13.81.129] (helo=[192.168.0.4]) by elasmtp-banded.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1GBRHl-0001Gq-5v; Fri, 11 Aug 2006 03:18:25 -0400
Mime-Version: 1.0
Message-Id: <a06230904c101d97e9894@[192.168.0.4]>
Date: Fri, 11 Aug 2006 00:18:13 -0700
To: Recipient List Suppressed:;
From: Hoyt L Kesterson II <[e-mail]>
Subject: The fifth edition of ITU-T X.509 / ISO/IEC 9594:2005
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-ELNK-Trace: 59f3edefb26af0321a6f9084d36cbc6474bf435c0eb9d47871f28e14d885ed8ced6d9a1e5188aabb716ab06a37b9c70b350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 130.13.81.129
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 fifth edition of ITU-T X.509 / ISO/IEC 9594:2005 has been 
published. It is available electronically and will soon be available 
as hard copy.

As before, ITU-T allows the downloading of three documents at no 
charge. The procedures have changed since I last described this 
service. Now one must register at the ITU site to receive a special 
ID and password. This is described at

http://www.itu.int/publications/template.aspx?media=download&target=/publications/EBookshop.html 


or go to the ITU-T main page at http://www.itu.int/home/index.html 
and follow the link to "Electronic Bookshop"

Once you have your special ID and password, download the August 2005 
(08/05) edition from

   http://www.itu.int/rec/T-REC-X.509/en

For languages other than English, one will follow a different path.

Note that this is a copyrighted document. One should not further 
distribute the document. Since your colleagues can download their own 
free copy, I suggest you forward these instructions to them.

Once registered, you are permitted to download three free documents. 
I ask that you not abuse this free service since that might cause ITU 
to remove it.

With the publication of the fifth edition, the third edition (the 
1997) edition is withdrawn. This means that only the fourth and fifth 
editions will be supported, i.e. defect resolution.

My thanks to all of you out there who contributed to this work.

      hoyt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k77L4XTh053841; Mon, 7 Aug 2006 14:04:33 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k77L4XqM053838; Mon, 7 Aug 2006 14:04:33 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from carter-zimmerman.mit.edu ([192.42.249.121]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k77L4TcY053804 for <[e-mail]>; Mon, 7 Aug 2006 14:04:33 -0700 (MST) (envelope-from [e-mail])
Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 7D20FE00C0; Mon,  7 Aug 2006 17:04:21 -0400 (EDT)
From: Sam Hartman <[e-mail]>
To: [e-mail]
Subject: AD review comments for draft-ietf-pkix-scvp-27
Date: Mon, 07 Aug 2006 17:04:21 -0400
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux)
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>

Hello.

As part of the publication process for draft-ietf-pkix-scvp-27 I have
reviewed the draft as the AD bringing it to the IESG.

I've found a few issues that I believe need to be handled before the
draft can be last called at the IETF level.  In many cases
clarifications of text will be sufficient to address these issues.
There are a few concerns about interoperability though.




Section 3: The text does not state a good reason why
anyExtendedKeyUsage is not sufficient for a cert to be used to sign
scvp requests.  Please either provide such a reason or require
servers to accept this keyPurposeID.  If you believe that some
environments may have a good reason to reject anyExtendedKeyUsage but
others will not, then state that servers SHOULD accept the usage and describe these differences.


>   All SCVP clients MUST support SignedData for signed requests and
>   responses.  SCVP clients SHOULD support AuthenticatedData for MAC
>   protected requests and responses.

What are the requirements for servers?


How does a client obtain the server's key agreement public key?  The
section 3 text says that the client must do so but does not describe
how.  Is a normative mechanism required here?  If not, you still need
to describe possible methods.

Section 3.1

The text claims the version must be increased for any change in syntax
or semantics.  Do I need to increase the version number when I define
an extension?  If not, please note this.



Section 3.2 The ASN.1 tagging for the Query type looks strange.  There
is no context tag 0; not all optional fields are tagged.  What is the
style being used here?



In 3.2.4.5 and 3.2.4.6, if the server does not support these flags,
must it error if they are set or can it ignore them?  The text is
unclear.  Later text implies that the server should generate an error
if these features are requested but they are not available; if so,
please clarify this text.



Section 3.2.4.9 does not provide sufficient semantics to meet the
needs of common applications.  For example
draft-ietf-cat-kerberos-pk-init requires that pk-init certificates
have the ExtendedKeyUsage extension in some cases.  SCVP itself does
not currently permit the anyExtendedKeyUsage value, so SCVP doesn't
even provide good enough extendedKeyUsage handling to validate SCVP
server certificates.  At a minimum support is required for cases where
EKU needs to be present and where anyKeyUsage is not acceptable.





Are all clients guaranteed to interoperate with all servers?  It seems
there is an incomplete overlap between DPD and DPV and it is not clear
that servers are required to support one of these configurations.
It's not clear that this meets RFC 2026's definition of
interoperability.  If so, that needs to be fixed.



Section 4:

>    1. A success response to a request made over a protected transport
>       such as TLS.  These responses SHOULD NOT be protected by the
>       server.

Why is that a should?  IT seems useful to protect such responses so
that for example they can be included by relaying scvp servers in
their responses while still preserving authentication.  In general,
TLS does not provide data origin authentication to third parties, but
protected responses do.




Section 6.1:


>   The syntax and semantics of the vpResponseVersion item are the same
>   as cvRequestVersion as described in section 3.1.  The
>   vpResponseVersion used MUST be the same as the vpRequestVersion
>   unless the client has used a value greater than the values the
>   server supports.  If the client submits a vpRequestVersion greater
>   than the version supported by the server, the server MUST return a
>   vpResponseVersion using the highest version number the server
>   supports as the version number.

Why is the above text necessary?  Shouldn't clients use the oldest
vpversion in their request to discover what vpversions the server
supports?  The above text is potentially hard to implement because it
assumes that future validation policy requests are backward compatible when parsed by an old parser.

i'm also not convinced that the above text is implementable given the
current ASN.1 syntax with a modern ASN.1 toolchain--one that treats
extra fields in a sequence as an error.  You can definitely implement
parsing all the versions you support by trying to parse each version
separately, but I'm not convinced that with such a tool chain you can
implement parsing part of a structure that is newer than you support.



How does a client discover what WantBacks and Checks a server
supports?


MIME

* the change controller for all IETF standards track mime
 registrations should be the IESG 

There is a required parameter (format) on all the mime types that is
 neither documented nor used in the HTTP samples.  I suspect this is
 not actually desired..

I think vp-request and vp-response are too generic of subtype names; 
 you can try to convince the ietf-types folks that they should  accept
 this but I suspect you will run into trouble.





Received: from gsnb.com (228.Red-83-44-30.dynamicIP.rima-tde.net [83.44.30.228]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k77DJ3oh012379 for <[e-mail]>; Mon, 7 Aug 2006 06:19:09 -0700 (MST) (envelope-from [e-mail])
Message-ID: <000001c6ba24$0ce6d040$59fea8c0@fou45>
Reply-To: "Abba Hetrick" <[e-mail]>
From: "Abba Hetrick" <[e-mail]>
To: [e-mail]
Subject: Re: bufaa
Date: Mon, 7 Aug 2006 06:19:02 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C6B9E9.6087F840"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106

This is a multi-part message in MIME format.

------=_NextPart_000_0001_01C6B9E9.6087F840
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_0002_01C6B9E9.6087F840"


------=_NextPart_001_0002_01C6B9E9.6087F840
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

=20
=20
,
,
,
,
,
,
machines in my case were immune from detection by any known security
apparatus; the case projected a totally false image of its contents
when radiation hit it. My step had been light, my smile broad.


------=_NextPart_001_0002_01C6B9E9.6087F840
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 content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>&nbsp;</DIV>
<DIV><IMG src=3D"cid:000101c6ba24$0ce48b32$59fea8c0@fou45"></IMG>
<DIV>,</DIV>
<DIV>,</DIV>
<DIV>,</DIV>
<DIV>,</DIV>
<DIV>,</DIV>
<DIV>,</DIV>
<DIV>machines  in my case were immune from detection by any known  =
security<BR>
apparatus;  the case projected a totally false image of  its  =
contents<BR>
when radiation hit it. My step had been light, my smile =
broad.<BR></DIV></BODY></HTML>
------=_NextPart_001_0002_01C6B9E9.6087F840--

------=_NextPart_000_0001_01C6B9E9.6087F840
Content-Type: image/gif;
	name="supreme97.gif"
Content-Transfer-Encoding: base64
Content-ID: <000101c6ba24$0ce48b32$59fea8c0@fou45>

R0lGODdhKgHeAMIAAP///wAA/wAAAP8AAGR2vwAAAAAAAAAAACwAAAAAKgHeAAAD/gi63P4wSkdU
nTiDq63mXSiOZGmeaKpO4Oq+8NvG0kzfuI1/e88uOlXQR4QNi6GjB9lQQpwMKHNKrU6HUqvWmt16
u96wuAgex8odrLnHCaLX8Lh8LqTbMe375v5+60l+f0k8gniFh4hpiYQugYuLjo+SipFClSuXiV0X
mZNAnqChRqKkiJ2iAg+pAKs2q6wQAQERsgCyt7i2uLUau7wLuw/BwL4iUll9pS+vDKvMDq/PxLMO
t7qx1ArWEtvE2r/d4by/utkZp06nyqoN0hju5XsM1uTz5t/c99f73vj2/v9yrBP0LNoCAQgNskr4
bFY9hxCxVdO3p14Di9cw1rKI/vEbuWEZt+VCckxdmIIHFTBzllIYP20hJU6USfOfxogzc9r6dmEc
uJ/n+CjaolClyhlFL2oj0BOfL3rmelJ8qdMmxY1X9XG8hzUgQEkmT4AAkZQltJbVAFLr2oSqv2Af
c910G7Pq17tsv3YcaOLYu5QXoiVECy/bRm8d5wrLSjev1cV2qTr+GPYHkcolUqGUtyTpPK91I++d
S5rxVshRZDFFbC4upj+ciMJqxm62baX9nE49TUvrWq6Ggd/l59PuZBB7hQpqobmd0ZYcmHGYio/A
7gDTk8cLKG5Whe4b4rYODkztb9AY1VXIQ3KNtFYM0S5smK9csacd8Nvrtl/8/kj0/IHkWm58jdAC
ZhEgWGAcCppCgRkN9rXghKKsZ5lYxjBIRYQUctFhUB+GOIoWHIpYIR0lojhIKZilSAp7oLiojIyf
mAgIDQ3SWOOJNdzIxhE6zmFSikHCMRYjNlax2V+cSQAPPHNACWIGUtqhYyfvdeDZWVnW9kBgZ0k4
RJWXVIlCkVEYSESXIlT5pAls3mCmC3M+YQGaj6w02AYIqbQnNH0202dz882mp23ODBqon4TCEh+j
zj160J6EUvqcABVQGmijdao5pY0EFMUpol7K19xKt3lgEKrOPecoYGiFSiphC7laqVGsOpprkikE
IiqpW6Z626mCsrNqKpmG/onrErr++epzyS5r66unCjbYkizegCWtq8rn7bDPSivPqH7K2qq03Rpr
akq/EitYqth+yesO0XHL7rfCotqooW2Vle+56YLrr7gKeTZqvDyGoYS1iZolrJ/tDGqoxK5OrOi7
xdqKqbWdzcqow4VOG3LIu6KIZ4JwIrlmCiXr0SlfaGKKZ7QotPwpEy/fbOeDJM4r0I4h5qgizyhr
uKLPGCLtAzIDneyj0QU6rfSFUwNdda+PoGkDkFcXIvWGkAwltidFqkF1wiobMrbOylldxdecnQx3
12d6esbcT9MtTyVo4K03GyyuhvUXZ/xtuNtdHwg12z77cYnfZx/OrOR5/lM+tOUmlghj0x1mkoze
ZQzZOOYT5Oxgmo3UEXnpL+ugINNIwDPA7LQ7UDsDs9s+AAC095677r7vroDvUfRue9CdOm16hlo+
8Pvwwi9w+wXPS7979RJgb/32vEdfffSM6xHY8szDkHNlyOIOfvfqs899+9pDED/2uT8/AAjrT7go
Iq1TaamkH9sf9CZQv/V9T3jxc17+3Lc9+3lvZ+q7HfuMp8D2QU+C9LueBvN3sXcBcD6LulitHgVA
hhREUxkjXwT0lSvpSEOCunsfA92XQOBh0IAa5B4CKRjDAXbPews8oA9pGL0KFJCHk0rfpkKIsVqB
UISQgpgTpxjCKTpR/oVU+lecrIdEBgpRh8GrIRgbUEAdejF/GZyhGmdYRg6UsXhrzNikrEjHOZpr
jniUIqDqiJDogCwSJtSisshIvPel8YwleGMDhUeA+g1Re2k8JCF9GEkcxjGPEBPg/hgiK00eCpMm
1Mwr/HgUb/mKNtKgWawedLswftGBicyhBQu5QxkOcQOKvOUY1ZjLCd5vhSek4xKL5clmkCVRxHTH
MCvGskhxaZAR+J0kiWjLDvQygUCkHhotmcYW5K6RtYTfLxfppGAW85zBBKUoI1ZHJ94xfSpASZa2
yECm9NKI4EOiGG15zSBacI2VnKQCG8lPWZITmOxEZ0LTqccRmvNJ/s4yHzHD9Ml/UrOHF8znAjGK
SF1K75/zA6IusQlDWD6ylxHDmEKTKMyKOlRQyNTYJisXhY2Faw8Mg4U3CxnHA/4On2HcUfAICUPc
2XCjPzTpHmoIyS4aD6XJZGJnGqaolsrxivFhYjFpAzjO6WGf8cRik1C3NLGmbmklCNLnqrk2hNKr
BwI00tU2JwKwhlUGU4jrvBw3OcJhDnJkVRjpBktYKyGNrz0rrGIX61eieRUsvAqL2f42N9gxFrJq
CwTc+tZV8V3WsSP6rLxo2tfXnG5wawBs3VYXWNEmjbRtsdtolzPby0xCtW9NbNEQx9rPbi1thyCS
bU1LBtca91Oa/qUR134Gm+PW1rnQhRlxVwu2y/GWbNVF6zpaFD61yXUouP3uaaP7WMEa9rmGC29v
Yyuk4oaWvPBNbXsTN6O3XZe97Slv1bAkQAu1VQ7KRW13ixDXTYXqPXp94hIDibqIQtMH34zgPnma
UaRSN7uHKHAT5+jJh141k1Iya13BB062nvR9BPUQaEO0SZeCmJ0QaPEeE8zMHQxVfha2KBxXrDoe
bwAM6lXnVTOlmWOW88MvjfG1RlZCktG4jCTVQJTp5ToVu8elW6ViiF0s1RhjElx6rGIFxWjXS5ZZ
a2PlLW6X+eUutzOPGgYClJRIFopytcYDDClYu5jU+IrtwA21/mqYGdZBvbpZWS6087pwTOYcm7jM
fk4hQxWsKaSsk4+hTLDBFO2qOzIaqWDFJ1khHemP7bHNMWXnO5kz6TsjDGSoCgJUL6k7G5A6sqQd
Ux9PHehDv1jISGbWqytmM3nMusxTLtxrJYThNjnY11KMaFUlrQplfmslYLJAsaEcTjaK9MQejVGP
84pgNl8104F+Kau9pExn7QpKN87oTiWMw6Jat9R/IPWt7ztc3eJ7BZDe93xzgGZNiCGBM7h1kP9N
2cPxbbf7DQU6WtujtCpt4WLgbvmOVtqOV8hzUWzsuJd9VsyGIJRJRPC6q93iDzqpPdoDZ6Nv7EoA
i2h8FY2z/oyVfO5n6MDnsK0gSB29S/TmdwtFojGmazU+ty5ECa5AQrw5Gs1vW5zZeM3tZdyEYCvS
GNoayCqT3e1keOfwefgjulKvcHUKKV3QWnb620e7YTDHHc++TJAYtUnvBWI8FJhiHYzvXm2Ymm7T
rYLntg0qYSmDmujrPTpYuD5VOKcy3SBsHjO79G6r8VnHqMPevD2O9Q/54e0tR/mbV896V5+rJe8e
wufDDXqBGr1zSiITl5H19S2HPdvXJrYxs8f42ltgz5D37mKJfGRUY/750AfY6y91Z0+PeaONxoDA
ld2zINnU8l/W9uoPPXdavX5geOc2uG8ZUhOP4e/87muo/g6c03YWutKEftkoWd55fFVYo0X1RUfF
dl6jfAviNKJHfMAlX/hlXuJFIeOUAdt3gDjCcc31X0QQcMmXcRQHOgNGIfC3XQz3ImkSgiMYaVJj
giTgYCdYgV9QYKzWaimHeVAEU14mddjnaBTmfqT3fqUQZxzmYnJkaKJUbjdYetqXgwRkdTx4XFmw
c0EYbIM2OR1keEfYA1M3e1XHRRv4b1D4a9AHdlWYRIJjeEU4g+yyYFvYTyNmey2YZl6Xc4E3fnX3
YsOkaXqkSk0kZjGUbJYxTX/lA+ZGeL0Xfi91h28yG8AHe3f2MHkndI5nO2XDgRW3Jqk2hWFYh0lG
QokI/nSJ14hm54dLCInTxVjmFkqARoeGOG2cGGOq9C9254hcSHVbSIragnuV6D9ZFm1zpomB52Z4
CC+cZne2VnwJ2CQRRosPyGLS1gq8CExNBw3M1y+d2DGfuGhraEmjWIul2IACRoIl1G6q6Hxv1idI
UWMtBIo4lndutE1NOIGltotBqHrxgXOSomnVCCgzhY02lGL/N3T3w0NTB0GF9ThB514xoG9diIFI
SJBax30QN1hnRmoqiJCDhSDHaIsu+IYWyZA9eDqdoDi3KG79BoIm6W8cqVjqUZIjuAkpKTl+MwMV
mYtUNpMvmXXxtzg+dpNMUHAGd3uHZXojd29hs3E8/kmUEXmUe9WNuHaCPildSaI5NoddKKiUBmiV
KImVkqeVQjk1bsCVSJeTB9lsCziSbSOWWQmWVjY6DkiWatmU7yVbTviRb4mUUUOA+sVckZde32g3
ZTKWTLmRfelZpXOFYiBijRh2Q4mL/PMgiEknErWTsuiQekmTF+iRI5CIBXJ4JOeBdElgR0hCAKN0
Ltcs79ZyRKN6mSeMk+la6TCYQOMO5qIv1+iILbOPHuMw8MAcwrcZj3lZVfaBZshgtQkyrQmLXGWc
rJmYD6ObOIWTMNlZpeJqokl9zBlAD2YWW3SOo2kpIrOYnQmSnymIN8gqBbMxLHibilZuLsd5yWl+
/m+IWGLzJgUBJsEyffSknQ+WnTplL/4Hlw0JB3PoTK72TkwSfNdIT/y5JEWGlnXZJl6GZec3SAXW
JM5pjXh2KBJ6nWvZlh2YYeW5ZPJBZPhIMaoyjO7GgqZGVbH4MPIZlgOXlnv5k3jnYxFikzBKmElp
BM4okgV4dRiHowaZMpKpln9XhkqJoyTZkkD5oZR4mVOZlxDppHapow9KgVypXkp6koFIo4LJliYT
cRd5pZTZdlH5pRi2pVU6XsIVpZajpGrqmpW5lQ66jEb5b8vFksK5o9pVlqqDNwgSp1AwM3iZLYQl
NDMqguA5XlS6qGQaoHLZk4+6pnfagHEanpN6TluZWqeb2qlz6qiB6qmNypeAqlYPKVo+KqpQqaov
eamsemFm2QNPMau0OqvWUau4mqu6uqu0equ8+qvA6qvAOqxPIazEWqvGeqzKuqsJAAA7

------=_NextPart_000_0001_01C6B9E9.6087F840--





Received: from acerubber.net ([89.124.71.236]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k75LsIrK064691 for <[e-mail]>; Sat, 5 Aug 2006 14:54:29 -0700 (MST) (envelope-from [e-mail])
Message-ID: <000001c6b8d9$b452b110$ab48a8c0@mfc79>
Reply-To: "Sacha Ferrer" <[e-mail]>
From: "Sacha Ferrer" <[e-mail]>
To: [e-mail]
Subject: Re: behyaVzlAGRA
Date: Sat, 5 Aug 2006 14:54:19 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C6B89F.07F3D910"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106

This is a multi-part message in MIME format.

------=_NextPart_000_0001_01C6B89F.07F3D910
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,
=20
VzlAGRA from 3, 35 $
CzlALIS from 3, 75 $
VALzlUM from 1, 25 $
AMBzlEN
=20
http://www.kioperade.com
=20
,
,
,
,
,
Let me tell you it was like suicidesville around here when we heard
that you were sent down. Should have known that you would have to end
up here. Wait until the boys in the barracks hear about this. Therell


------=_NextPart_000_0001_01C6B89F.07F3D910
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 content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hi,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>VzlAGRA from  3, 35 $</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>CzlALIS from  3, 75 $</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>VALzlUM from  1, 25 $</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>AMBzlEN</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;</FONT></DIV>
<DIV><DIV><FONT face=3DArial size=3D2><A =
href=3D"http://www.kioperade.com">http://www.kioperade.com</A></FONT></DI=
V>
<DIV><DIV><FONT face=3DArial size=3D2>&nbsp;</FONT></DIV>
<DIV><DIV><FONT face=3DArial size=3D2>,</FONT></DIV>
<DIV><DIV><FONT face=3DArial size=3D2>,</FONT></DIV>
<DIV><DIV><FONT face=3DArial size=3D2>,</FONT></DIV>
<DIV><DIV><FONT face=3DArial size=3D2>,</FONT></DIV>
<DIV><DIV><FONT face=3DArial size=3D2>,</FONT></DIV>
<DIV><DIV><FONT face=3DArial size=3D2>Let  me  tell you it was like =
suicidesville around here when we  heard<BR>
that you were sent down. Should have known that you would have to  =
end<BR>
up here. Wait until the boys in the barracks hear about this. =
Therell<BR></FONT></DIV></BODY></HTML>
------=_NextPart_000_0001_01C6B89F.07F3D910--





Received: from BcuChurchServer ([206.135.16.151]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k73JuB6b074166; Thu, 3 Aug 2006 12:56:11 -0700 (MST) (envelope-from [e-mail])
Received: from User ([221.161.189.242]) by BcuChurchServer with Microsoft SMTPSVC(5.0.2195.6713); Wed, 2 Aug 2006 12:56:18 +0900
Reply-To: <[e-mail]>
From: "PayPal Security"<[e-mail]>
Subject: Case ID Number:PP-084-160-904
Date: Fri, 4 Aug 2006 04:56:10 +0900
MIME-Version: 1.0
Content-Type: text/html; charset="Windows-1251"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Bcc:
Message-ID: <BCUCHURCHSERVERj7P300003624@BcuChurchServer>
X-OriginalArrivalTime: 02 Aug 2006 03:56:18.0906 (UTC) FILETIME=[9C2F5BA0:01C6B5E7]

<body>
<style>
BODY, TD
{font-family:verdana,arial,helvetica,sans-serif;font-size:12px;color:#000000;}
LI
{line-height:120%;}
UL.smallBorder
{;}
LI.smallBorderLi
{;}
UL.Narrow
{;}
HR.dotted
{width:100%;border-left:#fff;border-right:#fff;border-top:#fff;border-bottom:2px
dotted #ccc;}
.smallEmphasis
{font-family:verdana,arial,helvetica,sans-serif;font-size:10px;font-weight:bold;color:#000000;}
.serifBig
{font-family:serif;font-size:20px;font-weight:bold;color:#000000;}
.serif
{font-family:serif;font-size:16px;color:#000000;}
.sansSerif
{font-family:verdana,arial,helvetica,sans-serif;font-size:16px;color:#000000;}
.heading
{font-family:verdana,arial,helvetica,sans-serif;font-size:18px;font-weight:bold;color:#003366;}
.subHeadingEoa
{font-family:verdana,arial,helvetica,sans-serif;font-size:15px;font-weight:bold;color:#000000;}
.subHeading
{font-family:verdana,arial,helvetica,sans-serif;font-size:16px;font-weight:bold;color:#003366;}
.sidebarText
{font-family:verdana,arial,helvetica,sans-serif;font-size:11px;color:#003366;}
.sidebarTextBold
{font-family:verdana,arial,helvetica,sans-serif;font-size:11px;font-weight:bold;color:#003366;}
.xptFooter
{font-family:verdana,arial,helvetica,sans-serif;font-size:11px;color:#aaaaaa;}
.button
{font-size:13px;font-family:verdana,arial,helvetica,sans-serif;font-weight:400;border-style:outset;color:#000000;background-color:#cccccc;}
.smaller
{font-family:verdana,arial,helvetica,sans-serif;font-size:10px;color:#000000;}
.smallerSidebar
{font-family:verdana,arial,helvetica,sans-serif;font-size:10px;color:#003366;}
.emphasis
{font-weight:700;}
table#invoice, table#invoice_controls,
table#invoice_note
{width:600px;}
table#invoice_note
{;}
table#invoice_controls
{text-align:right;}
table#invoice
{border-collapse:collapse;border:1px solid #aaa;}
table#invoice td
{font-size:11px;border:1px solid #ccc;padding:2px;}
table#invoice td.field_label_right, table#invoice
td.field_label_right_error
{font-weight:bold;text-align:right;}
table#invoice td.field_label_right_error,
table#invoice td.field_label_error
table#invoice tr.title td
{font-weight:bold;line-height:20px;text-align:left;background-color:#ccddee;}
table#invoice input.readonly
{border:0;text-align:right;}
table#invoice input.readonly_currency
{border:0;width:10px;}
.field_error, .field_error input.readonly_currency
{background-color:#FF3333;}
.currency_highlight
{background-color:#ffffcc;}
.tax
{font-weight:400;float:left;}
table#invoice td span.curr
{float:left;}
table#invoice td.currency
{border-right:1px solid #fff;}
table#invoice td.calc
{font-weight:bold;text-align:right;}
.inlineBlue
{color:#00f;}
.small
{font-size:11px;font-weight:400;}
HR.solid
{width:100%;border-left:#fff;border-right:#fff;border-top:#fff;border-bottom:2px
solid #999;}
.large
{font-size:17px;}
.smallVerdanaGrey
{font-family:verdana;font-size:10px;color:#999999;}
.smallVerdana
{font-family:verdana;font-size:10px;color:#000000;}
.smallArial
{font-family:arial;font-size:13px;}
.smallArialBlue
{font-family:verdana;font-size:9px;color:#0000FF;}
.smallVerdanaGreen
{font-family:verdana;font-size:10px;color:#666666;}
.smaller
{font-size:10px;color:gray;}
.larger
{font-size:18px;font-family:arial;font-weight:600;}
.longTableValue
{word-break:break-all;}
.longSideBarText
{width:190px;word-break:break-all;}
</style>
<div>
<table align=center border=0 cellpadding=0
cellspacing=0 width=600><tr valign=top><td><a
href="http://221.139.180.61/www.paypal.com/index.php"><img
src="http://images.paypal.com/en_US/i/logo/email_logo.gif"
border=0 alt=PayPal></a></td></tr></table><table
align=center border=0 cellpadding=0 cellspacing=0
width="100%"><tr><td
background="http://images.paypal.com/en_US/i/scr/bg_clk.gif"
width="100%"><img alt="" border=0 height=29
src="http://images.paypal.com/en_US/i/scr/pixel.gif"
width=1></td></tr><tr><td><img alt="" border=0
height=10
src="http://images.paypal.com/en_US/i/scr/pixel.gif"
width=1></td></tr></table><table align=center border=0
cellpadding=0 cellspacing=0
width=600><tr><td></tr></table><table align=center
border=0 cellpadding=0 cellspacing=0 width=600><tr
valign=top><td width="100%"><table align=right
bgcolor="#cccccc" border=0 cellpadding=1 cellspacing=0
width=190><tr><td><table align=center
bgcolor="#ffffff" border=0 cellpadding=0 cellspacing=0
width="100%"><tr><td><table align=center
bgcolor="#eeeeee" border=0 cellpadding=5 cellspacing=0
width="100%"><tr><td align=center><span
class=sideBarTextBold>Protect Your Account
Info</span></td></tr></table><table align=center
border=0 cellpadding=5 cellspacing=0
width="100%"><tr><td class=sideBarText
bgcolor="#ffffff">Make sure you never provide your
password to fraudulent websites.<br><br>
PayPal will never ask you to enter your password in an
email.<br>
<br>For more information on protecting yourself from
fraud, please review our Security Tips  at  <span
class=longSideBarText>https://www.paypal.com/us/securitytips</span><br><img
alt="" border=0 height=5
src="http://images.paypal.com/en_US/i/scr/pixel.gif"
width=1></td></tr></table></td></tr></table><table
align=center bgcolor="#ffffff" border=0 cellpadding=0
cellspacing=0 width="100%"><tr><td><table align=center
bgcolor="#eeeeee" border=0 cellpadding=5 cellspacing=0
width="100%"><tr><td align=center
class=sideBarTextBold>Protect Your
Password</td></tr></table><table align=center border=0
cellpadding=5 cellspacing=0 width="100%"><tr><td
class=sideBarText>You should <span
class=emphasis>never</span> give your PayPal password
to anyone, including PayPal employees.<br><img alt=""
border=0 height=5
src="http://images.paypal.com/en_US/i/scr/pixel.gif"
width=1></td></tr></table></td></tr></table></td></tr><tr><td></tr></table>

<span class=heading>PayPal Account Limited <br>
</span>
<p><strong> Dear PayPal Member,</strong>
<p><p><font size="2" face="Verdana, Arial, Helvetica, sans-serif"><strong>Paypal</strong> is constantly working to ensure security by regulary screening the accounts in our system.We recently reviewed your account,and we need more information to help us provide you with secure service.Until we can collect this information,your access to sensitive account features will be limited.We would like to restore your acces as soon as possible,and we apologize for the inconvenience.<br><br>
  <strong>Why is my account access limited?</strong><br><br>
  Your account access has been limited for the following reason(s):<br><br>
		     
		      <font size="2" face="Verdana, Arial, Helvetica, sans-serif">
							We would like to ensure that your account was not accessed by an unauthorized third party.Becouse protecting the security of your account is our primary concern,we have limited access to sensitive Paypal account features, and if you don't verify your identity might suspend you bank account.We understanding that this may be an inconvenience but please understand that this temporary limitation is for your protection.Case ID Number:PP-084-160-904<br><br>
		     
		      <font size="2" face="Verdana, Arial, Helvetica, sans-serif">
							
</p>
You must click the link below and enter your information to review your account:

<strong></font> <p align=left><font face="Verdana, Arial, Helvetica, sans-serif" <font <font color="black"><a 
href="http://221.139.180.61/www.paypal.com/index.php">Click here to visit the Resolution Center and<br>
complete the Steps to Remove Limitations </a></font></p>
</strong>
<p>Sincerely,<br>
  The PayPal Team</p>
<hr class=dotted>



<span class=xptFooter>Please do not reply to this
email. This mailbox is not monitored and you will not
receive a response. For assistance, <a
href="http://221.139.180.61/www.paypal.com/index.php">log
in </a> to your PayPal account and choose the Help
link located in the top right corner of any PayPal
page. <br>

  <br>
PayPal Email ID<strong> PP295</strong></span></td>
</tr>
</table>
</div>

</body>



Received: from cheinc.com (adsl-ull-205-196.41-151.net24.it [151.41.196.205]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k72D2iFp059499 for <[e-mail]>; Wed, 2 Aug 2006 06:02:51 -0700 (MST) (envelope-from [e-mail])
Message-ID: <000001c6b634$75c2e7a0$fd1fa8c0@kjn38>
Reply-To: "Ernesta Alex" <[e-mail]>
From: "Ernesta Alex" <[e-mail]>
To: [e-mail]
Subject: Re: serusVjiagra
Date: Wed, 2 Aug 2006 06:06:25 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C6B5F9.C9640FA0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106

This is a multi-part message in MIME format.

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

Hi,
=20
Ambjien
Vjiagra from 3, 35 $
Valjium from 1, 25 $
Cjialis from 3, 75 $
=20
http://www.bukeradesaxin.com
=20
,
,
,
,
,
information, the instigator of the operation.
Admiral Benbow!
Im afraid that information is not mine to reveal.


------=_NextPart_000_0001_01C6B5F9.C9640FA0
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 content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hi,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Ambjien</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Vjiagra from 3, 35 $</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Valjium from 1, 25 $</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Cjialis from 3, 75 $</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;</FONT></DIV>
<DIV><DIV><FONT face=3DArial size=3D2><A =
href=3D"http://www.bukeradesaxin.com">http://www.bukeradesaxin.com</A></F=
ONT></DIV>
<DIV><DIV><FONT face=3DArial size=3D2>&nbsp;</FONT></DIV>
<DIV><DIV><FONT face=3DArial size=3D2>,</FONT></DIV>
<DIV><DIV><FONT face=3DArial size=3D2>,</FONT></DIV>
<DIV><DIV><FONT face=3DArial size=3D2>,</FONT></DIV>
<DIV><DIV><FONT face=3DArial size=3D2>,</FONT></DIV>
<DIV><DIV><FONT face=3DArial size=3D2>,</FONT></DIV>
<DIV><DIV><FONT face=3DArial size=3D2>information, the instigator of the =
operation.<BR>
 Admiral Benbow!<BR>
 Im afraid that information is not mine to =
reveal.<BR></FONT></DIV></BODY></HTML>
------=_NextPart_000_0001_01C6B5F9.C9640FA0--





Received: from capro.com (195-23-76-176.net.novis.pt [195.23.76.176]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k7198cZW034972 for <[e-mail]>; Tue, 1 Aug 2006 02:08:43 -0700 (MST) (envelope-from [e-mail])
Message-ID: <000001c6b54a$447455c0$9758a8c0@vfw92>
Reply-To: "Toribio Lukowski" <[e-mail]>
From: "Toribio Lukowski" <[e-mail]>
To: [e-mail]
Subject: Re: vooekVijagra
Date: Tue, 1 Aug 2006 02:10:00 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C6B50F.98157DC0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106

This is a multi-part message in MIME format.

------=_NextPart_000_0001_01C6B50F.98157DC0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,
=20
Ambijen
Valijum from 1, 25 $
Cijalis from 3, 75 $
Vijagra from 3, 35 $
=20
http://www.rumolastigabun.com
=20
,
,
,
,
,
The sun was a glowing crimson disk on the horizon when me reached the
market. The Fundamentaloid nomads must lave been early risers because
everything was in great swing already. I ready. And gory too; I


------=_NextPart_000_0001_01C6B50F.98157DC0
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 content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hi,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Ambijen</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Valijum from 1, 25 $</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Cijalis from 3, 75 $</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Vijagra from 3, 35 $</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;</FONT></DIV>
<DIV><DIV><FONT face=3DArial size=3D2><A =
href=3D"http://www.rumolastigabun.com">http://www.rumolastigabun.com</A><=
/FONT></DIV>
<DIV><DIV><FONT face=3DArial size=3D2>&nbsp;</FONT></DIV>
<DIV><DIV><FONT face=3DArial size=3D2>,</FONT></DIV>
<DIV><DIV><FONT face=3DArial size=3D2>,</FONT></DIV>
<DIV><DIV><FONT face=3DArial size=3D2>,</FONT></DIV>
<DIV><DIV><FONT face=3DArial size=3D2>,</FONT></DIV>
<DIV><DIV><FONT face=3DArial size=3D2>,</FONT></DIV>
<DIV><DIV><FONT face=3DArial size=3D2> The sun was a glowing crimson =
disk on the horizon when me reached the<BR>
market.  The Fundamentaloid nomads must lave been early risers =
because<BR>
everything  was  in  great swing already. I ready.  And  gory  too;  =
I<BR></FONT></DIV></BODY></HTML>
------=_NextPart_000_0001_01C6B50F.98157DC0--