- From: merlin <merlin@baltimore.ie>
- Date: Tue, 29 Aug 2000 17:31:28 +0100
- To: Philip Hallam-Baker <pbaker@verisign.com>
- Cc: "'Barb Fox'" <bfox@Exchange.Microsoft.com>, Gregor Karlinger <gregor.karlinger@iaik.at>, w3c-ietf-xmldsig@w3.org
Algorithm URIs can and should be used to solve the versioning problem.
Deriving meaning from an OID would make XMLDSIG _really_ dependent upon
an ASN.1 parser. Requiring that a crypto toolkit can process the OID
within a signature is only to be expected, and is an orthogonal issue.
Merlin
r/pbaker@verisign.com/2000.08.29/09:19:41
>This is a multi-part message in MIME format.
>
>------=_NextPart_000_0009_01C011B3.9581E4F0
>Content-Type: multipart/alternative;
> boundary="----=_NextPart_001_000A_01C011B3.9581E4F0"
>
>
>------=_NextPart_001_000A_01C011B3.9581E4F0
>Content-Type: text/plain;
> charset="iso-8859-1"
>Content-Transfer-Encoding: 7bit
>
>Actually there is an advantage, consider that there is more than one
>PKCS#1 version. The OID describes the specific packing format.
>
>The verifier MUST understand the OID in order to correctly verify the
>signature in any case - the OID is embedded in the packing format to
>prevent a digest substitution attack. The OID in the message MAY occur
>in different octet positions depending on the packing format. It is
>useful to know in advance where the inner OID is positioned in order to
>correctly validate the signature.
>
> Phill
>
>-----Original Message-----
>From: Barb Fox [mailto:bfox@Exchange.Microsoft.com]
>Sent: Tuesday, August 29, 2000 11:13 AM
>To: Gregor Karlinger; merlin; w3c-ietf-xmldsig@w3.org
>Subject: RE: XMLDSIG RSA signatures
>
>
>
>The reason that I added this as a MAY is because many toolkits
>automatically pre-pend that OID in an RSA signature.
>
>--Barb
>
>-----Original Message-----
>From: Gregor Karlinger [ mailto:gregor.karlinger@iaik.at
><mailto:gregor.karlinger@iaik.at> ]
>Sent: Tuesday, August 29, 2000 7:02 AM
>To: merlin; w3c-ietf-xmldsig@w3.org
>Subject: AW: XMLDSIG RSA signatures
>
>
>Hi all,
>
>I agree with Merlin, providing the option to wrap the RSA signature
>octets
>into
>a ASN.1 structure, however it looks like
>
> * has no benefits ,
> * adds options which result in a more complicated verification
>process,
> * is confusing (I had to read the text in 6.4.2 some times to get it).
>
>
>Therefore I also vote to kick this option out.
>
>Regards, Gregor
>---------------------------------------------------------------
>Gregor Karlinger
>mailto://gregor.karlinger@iaik.at <mailto://gregor.karlinger@iaik.at>
>http://www.iaik.at <http://www.iaik.at>
>Phone +43 316 873 5541
>Institute for Applied Information Processing and Communications
>Austria
>---------------------------------------------------------------
>
>
>> Hi,
>>
>> In 6.4.2, regarding RSA signatures, the following wording exists:
>>
>> A signature MAY contain a pre-pended algorithm object identifier,
>> but the availability of an ASN.1 parser and recognition of OIDs is
>> not required of a signature verifier.
>>
>> Does this mean that a signature may be (before base 64 encoding):
>>
>> SEQUENCE { SEQUENCE { OID . NULL } . BIT_STRING { SIGNATURE_VALUE }
>}
>> or:
>> SEQUENCE { OID . NULL } . BIT_STRING { SIGNATURE_VALUE }
>> or:
>> SEQUENCE { OID . NULL } . SIGNATURE_VALUE
>> or:
>> OID . SIGNATURE_VALUE
>>
>> Or, is it suggesting that the OID _within_ the RSA signature
>> (before crypting) is optional?
>>
>> Regardless, I think it adds options and thus confusion and thus
>> deserves, perhaps, to be eliminated..
>>
>> merlin
>>
>>
>>
>
>
>------=_NextPart_001_000A_01C011B3.9581E4F0
>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">
><TITLE>RE: XMLDSIG RSA signatures</TITLE>
>
><META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR></HEAD>
><BODY>
><DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
>class=3D535561516-29082000>Actually there is an advantage, consider that =
>there is=20
>more than one PKCS#1 version. The OID describes the specific packing=20
>format.</SPAN></FONT></DIV>
><DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
>class=3D535561516-29082000></SPAN></FONT> </DIV>
><DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
>class=3D535561516-29082000>The=20
>verifier MUST understand the OID in order to correctly verify the =
>signature in=20
>any case - the OID is embedded in the packing format to prevent a digest =
>
>substitution attack. The OID in the message MAY occur in different octet =
>
>positions depending on the packing format. It is useful to know in =
>advance where=20
>the inner OID is positioned in order to correctly validate the=20
>signature.</SPAN></FONT></DIV>
><DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
>class=3D535561516-29082000></SPAN></FONT> </DIV>
><DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
>class=3D535561516-29082000> =20
>Phill</SPAN></FONT></DIV>
><BLOCKQUOTE=20
>style=3D"BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: =
>0px; PADDING-LEFT: 5px">
> <DIV align=3Dleft class=3DOutlookMessageHeader dir=3Dltr><FONT =
>face=3DTahoma=20
> size=3D2>-----Original Message-----<BR><B>From:</B> Barb Fox=20
> [mailto:bfox@Exchange.Microsoft.com]<BR><B>Sent:</B> Tuesday, August =
>29, 2000=20
> 11:13 AM<BR><B>To:</B> Gregor Karlinger; merlin;=20
> w3c-ietf-xmldsig@w3.org<BR><B>Subject:</B> RE: XMLDSIG RSA=20
> signatures<BR><BR></DIV></FONT><!-- Converted from text/plain format =
>-->
> <P><FONT size=3D2>The reason that I added this as a MAY is because =
>many toolkits=20
> automatically pre-pend that OID in an RSA signature. </FONT></P>
> <P><FONT size=3D2>--Barb</FONT> </P>
> <P><FONT size=3D2>-----Original Message-----</FONT> <BR><FONT =
>size=3D2>From:=20
> Gregor Karlinger [<A=20
> =
>href=3D"mailto:gregor.karlinger@iaik.at">mailto:gregor.karlinger@iaik.at<=
>/A>]</FONT>=20
> <BR><FONT size=3D2>Sent: Tuesday, August 29, 2000 7:02 AM</FONT> =
><BR><FONT=20
> size=3D2>To: merlin; w3c-ietf-xmldsig@w3.org</FONT> <BR><FONT =
>size=3D2>Subject:=20
> AW: XMLDSIG RSA signatures</FONT> </P><BR>
> <P><FONT size=3D2>Hi all,</FONT> </P>
> <P><FONT size=3D2>I agree with Merlin, providing the option to wrap =
>the RSA=20
> signature octets</FONT> <BR><FONT size=3D2>into</FONT> <BR><FONT =
>size=3D2>a ASN.1=20
> structure, however it looks like</FONT> </P>
> <P><FONT size=3D2> * has no benefits ,</FONT> <BR><FONT =
>size=3D2> *=20
> adds options which result in a more complicated verification =
>process,</FONT>=20
> <BR><FONT size=3D2> * is confusing (I had to read the text in =
>6.4.2 some=20
> times to get it).</FONT> </P>
> <P><FONT size=3D2>Therefore I also vote to kick this option =
>out.</FONT> </P>
> <P><FONT size=3D2>Regards, Gregor</FONT> <BR><FONT=20
> =
>size=3D2>---------------------------------------------------------------<=
>/FONT>=20
> <BR><FONT size=3D2>Gregor Karlinger</FONT> <BR><FONT size=3D2><A=20
> =
>href=3D"mailto://gregor.karlinger@iaik.at">mailto://gregor.karlinger@iaik=
>.at</A></FONT>=20
> <BR><FONT size=3D2><A =
>href=3D"http://www.iaik.at">http://www.iaik.at</A></FONT>=20
> <BR><FONT size=3D2>Phone +43 316 873 5541</FONT> <BR><FONT =
>size=3D2>Institute for=20
> Applied Information Processing and Communications</FONT> <BR><FONT=20
> size=3D2>Austria</FONT> <BR><FONT=20
> =
>size=3D2>---------------------------------------------------------------<=
>/FONT>=20
> </P><BR>
> <P><FONT size=3D2>> Hi,</FONT> <BR><FONT size=3D2>></FONT> =
><BR><FONT=20
> size=3D2>> In 6.4.2, regarding RSA signatures, the following =
>wording=20
> exists:</FONT> <BR><FONT size=3D2>></FONT> <BR><FONT =
>size=3D2>> =20
> A signature MAY contain a pre-pended algorithm object =
>identifier,</FONT>=20
> <BR><FONT size=3D2>> but the availability of an ASN.1 =
>parser and=20
> recognition of OIDs is</FONT> <BR><FONT size=3D2>> not =
>required=20
> of a signature verifier.</FONT> <BR><FONT size=3D2>></FONT> =
><BR><FONT=20
> size=3D2>> Does this mean that a signature may be (before base 64=20
> encoding):</FONT> <BR><FONT size=3D2>></FONT> <BR><FONT=20
> size=3D2>> SEQUENCE { SEQUENCE { OID . NULL } . =
>BIT_STRING {=20
> SIGNATURE_VALUE } }</FONT> <BR><FONT size=3D2>> or:</FONT> =
><BR><FONT=20
> size=3D2>> SEQUENCE { OID . NULL } . BIT_STRING { =
>SIGNATURE_VALUE=20
> }</FONT> <BR><FONT size=3D2>> or:</FONT> <BR><FONT =
>size=3D2>> =20
> SEQUENCE { OID . NULL } . SIGNATURE_VALUE</FONT> <BR><FONT =
>size=3D2>>=20
> or:</FONT> <BR><FONT size=3D2>> OID . =
>SIGNATURE_VALUE</FONT>=20
> <BR><FONT size=3D2>></FONT> <BR><FONT size=3D2>> Or, is it =
>suggesting that=20
> the OID _within_ the RSA signature</FONT> <BR><FONT size=3D2>> =
>(before=20
> crypting) is optional?</FONT> <BR><FONT size=3D2>></FONT> <BR><FONT =
>
> size=3D2>> Regardless, I think it adds options and thus confusion =
>and=20
> thus</FONT> <BR><FONT size=3D2>> deserves, perhaps, to be =
>eliminated..</FONT>=20
> <BR><FONT size=3D2>></FONT> <BR><FONT size=3D2>> merlin</FONT> =
><BR><FONT=20
> size=3D2>></FONT> <BR><FONT size=3D2>></FONT> <BR><FONT =
>size=3D2>></FONT>=20
> </P></BLOCKQUOTE></BODY></HTML>
>
>------=_NextPart_001_000A_01C011B3.9581E4F0--
>
>------=_NextPart_000_0009_01C011B3.9581E4F0
>Content-Type: application/x-pkcs7-signature;
> name="smime.p7s"
>Content-Transfer-Encoding: base64
>Content-Disposition: attachment;
> filename="smime.p7s"
>
>MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINaDCCAj0w
>ggGmAhEAulrJTAU7ktantt9O0FOSDTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUG
>A1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVibGljIFByaW1hcnkgQ2Vy
>dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMDQwMTA3MjM1OTU5WjBfMQsw
>CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVi
>bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0A
>MIGJAoGBALZai6MNaiODgGvPOYf0IRMzBkwlou1VEpfFp4C5+oPBIKD6LxUNfKFga355LPoGDzqu
>9htvsdL/LyhSX4N9S8R6t/hmH4BU/LfCjllKFFdG0ZqTvkGRA7sVgJNc6+fMCGw/PrNK/P9LbCPV
>UIImRBmOI8Nx6hkkRwSedb/IpgAfAgMBAAEwDQYJKoZIhvcNAQECBQADgYEAtgAfk1ekB6dAzmVA
>P1Ve7e/6VEmlMNYhfGGH7oOTC7+0M/KYrJ8Gv06ozhSBTMsETljDz1/ufNeab8tBird/gbj/hGHG
>J0NlHQzssQAK3Ruku8d4ICiyot02lS7hVE+/YLl3aBGZI+jqUuiqAE5nTruQtUWbRuuOFu/EM1sz
>PdUwggNDMIICrKADAgECAhAffl/nA9Hgv5kg3GuJDUsEMA0GCSqGSIb3DQEBBAUAMF8xCzAJBgNV
>BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMiBQdWJsaWMg
>UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05OTAyMjUwMDAwMDBaFw0wNDAxMDUy
>MzU5NTlaMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1
>c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93
>d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEmMCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQ
>ZXJzb25uZWwgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKcEbA+icrdKBi741yksNJ2C
>vEiRSses+en8uVl4sVXAU1ixz28WO8FJ1cv0bszhzMu1xy5OiKo06bbQW3w+FVc04Ri8/931r2dZ
>IArlPeqIikDSmokTKam21dunfuHnNyST/ZR0TXrkMm1M6FwWl6/dktlmihRm5OpaA6g9X/sLAgMB
>AAGjgbAwga0wMQYDVR0fBCowKDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMi5j
>cmwwEQYJYIZIAYb4QgEBBAQDAgEGMEcGA1UdIARAMD4wPAYLYIZIAYb4RQEHAQEwLTArBggrBgEF
>BQcCARYfaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rcjAPBgNVHRMECDAGAQH/AgEBMAsG
>A1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQB59xXN6GhRWWv8qaa94B77vPQ/kN/n+u3kVPdh
>PVSLBrqXMloeqyzur3Orx13TP4/0zstOSGCiqGC2ON6gpvePKegRrMw5dlA83TlsC/Fa/QhUdt0W
>bPcxcLi/CPfJJgaO37svGbG2uLToPEjoJ7GXKSBXA5ybZ/p9QMQ4fxiqmjCCA8QwggMtoAMCAQIC
>EQCEzvIOADm1dVXaGYePUu2JMA0GCSqGSIb3DQEBBAUAMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwg
>SW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1
>YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEm
>MCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQZXJzb25uZWwgQ0EwHhcNOTkwMjI1MDAwMDAwWhcN
>MDQwMTA0MjM1OTU5WjCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT
>aWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJqZWN0IHRvIHRlcm1zIGF0IGh0
>dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAjBgNVBAMTHFZlcmlTaWduIENs
>YXNzIDIgRW1wbG95ZWUgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMCK0YdhouowA1Vr
>CDbwl/oaVDUkH+h9ncjDc9PYRvWRLdk47ZTXsCZzKt6XUE3/Ihy9cACYDFgqsaRyj6W59y18YOO1
>3+l9TiEhYdX8O1TJpAmcuyL5orpwYU+GRqL9BWTsCj+mWHZXuxZzRHzwpQ2XwGym8WMIJbEEF5Wg
>jf5/AgMBAAGjgeIwgd8wKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMTE4
>MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL1ZTQ2xhc3MySW50LmNy
>bDARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUF
>BwIBFh9odHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyMA8GA1UdEwQIMAYBAf8CAQAwCwYD
>VR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBABlGztRrcI5YXIhCNa0WfaUJLKhTkPH2PYbX8M5y
>FD0ivPLDM+3U/AWa4GMgdaMb71UZDwZzIQJhrqaeUSt43FvIhIvV17bP1fg+l5ixRIujmI6gS/aY
>MZOz8AzdUXbKl+RWRMb7lKFIfSJDzKDGXHlV9WeBG2iYNCREsZjBOiheMIIEFDCCA32gAwIBAgIQ
>AxTuqrYcesW8jpUyudZ0/DANBgkqhkiG9w0BAQQFADCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIElu
>Yy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJq
>ZWN0IHRvIHRlcm1zIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAj
>BgNVBAMTHFZlcmlTaWduIENsYXNzIDIgRW1wbG95ZWUgQ0EwHhcNOTkxMjIwMDAwMDAwWhcNMDAx
>MjE5MjM1OTU5WjBsMREwDwYDVQQKEwhWRVJJU0lHTjELMAkGA1UECxMCSFExEzARBgNVBAMTClJl
>Y2lwaWVudHMxNTAzBgNVBAMTLHBiYWtlciAoUGhpbGlwIEhhbGxhbS1CYWtlciwgVmVyaVNpZ24s
>IEluYy4pMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC3f0kRIy2AU5cHhfnUwuHecFNq6dnf
>/wsvxS//4Nt8rFgr2KdvQETKaQ6wGl6mVijB6udZW9dUKVoE1lnu2MMcIhtAL3+Q2dsrxlrTInfq
>PKAdxu/Fvb4n3Y0RItW9zh1MzFWZ8Q9z6eF2HuBwG6ANfRzfJgironyftbbitRyaxQIDAQABo4IB
>dDCCAXAwCQYDVR0TBAIwADBVBgNVHR8ETjBMMEqgSKBGhkRodHRwOi8vb25zaXRlY3JsLnZlcmlz
>aWduLmNvbS9WZXJpU2lnbkluY0V4Y2hhbmdlRW1wbG95ZWVzL0xhdGVzdENSTDALBgNVHQ8EBAMC
>BaAwHgYDVR0RBBcwFYETcGJha2VyQHZlcmlzaWduLmNvbTCBrAYDVR0gBIGkMIGhMIGeBgtghkgB
>hvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggr
>BgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4g
>YnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeA
>MB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjANBgkqhkiG9w0BAQQFAAOBgQAaUApBXCjc
>mPE5dFPHlQVl4n9WoOU7AE487xxC7vcR1MDhF8p/0GMu6zOyZe9CFVaOndaYCRgv69qKTVoANmsM
>F/eFsQn/HaoXEz+jHPNgWcPyBu3dujO9s2PLQbuBXE3rIaDiVyTftVgoNvO0fcknSlNOWxqHvbaH
>9RYvhMghkjGCAvgwggL0AgEBMIHBMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE
>CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVy
>bXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMcVmVy
>aVNpZ24gQ2xhc3MgMiBFbXBsb3llZSBDQQIQAxTuqrYcesW8jpUyudZ0/DAJBgUrDgMCGgUAoIIB
>jDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMDA4MjkxNjIwNTda
>MCMGCSqGSIb3DQEJBDEWBBSXyodPCp6IdjKnOZzJd8rhlqEWgTBYBgkqhkiG9w0BCQ8xSzBJMAoG
>CCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMC
>GjAKBggqhkiG9w0CBTCB0gYJKwYBBAGCNxAEMYHEMIHBMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwg
>SW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1
>YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEl
>MCMGA1UEAxMcVmVyaVNpZ24gQ2xhc3MgMiBFbXBsb3llZSBDQQIQAxTuqrYcesW8jpUyudZ0/DAN
>BgkqhkiG9w0BAQEFAASBgDdPIzGJqGfww691+8jBkrw0Js/h4Ol4Weo5va3pEZbTtuSN/GlCEPLk
>2FtqO5xs1Vtdut5MaqEE16yAMMgvvmlGfg5spD8Hoo7aimhzQYZ5CD/eCCu8hnkh43fgymrDPStR
>AudVk3jhGF+/Eou/BGXSmXTfpww+3AFA5/sQQVPLAAAAAAAA
>
>------=_NextPart_000_0009_01C011B3.9581E4F0--
>
Received on Tuesday, 29 August 2000 12:32:14 UTC