W3C home > Mailing lists > Public > w3c-ietf-xmldsig@w3.org > July to September 2000

Re: XMLDSIG RSA signatures

From: merlin <merlin@baltimore.ie>
Date: Tue, 29 Aug 2000 17:31:28 +0100
Message-Id: <200008291631.RAA01906@cougar.baltimore.ie>
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>&nbsp;</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>&nbsp;</DIV>
><DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
>class=3D535561516-29082000>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=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>&nbsp; * has no benefits ,</FONT> <BR><FONT =
>size=3D2>&nbsp; *=20
>  adds options which result in a more complicated verification =
>process,</FONT>=20
>  <BR><FONT size=3D2>&nbsp; * 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>&gt; Hi,</FONT> <BR><FONT size=3D2>&gt;</FONT> =
><BR><FONT=20
>  size=3D2>&gt; In 6.4.2, regarding RSA signatures, the following =
>wording=20
>  exists:</FONT> <BR><FONT size=3D2>&gt;</FONT> <BR><FONT =
>size=3D2>&gt;&nbsp;&nbsp;=20
>  A signature MAY contain a pre-pended algorithm object =
>identifier,</FONT>=20
>  <BR><FONT size=3D2>&gt;&nbsp;&nbsp; but the availability of an ASN.1 =
>parser and=20
>  recognition of OIDs is</FONT> <BR><FONT size=3D2>&gt;&nbsp;&nbsp; not =
>required=20
>  of a signature verifier.</FONT> <BR><FONT size=3D2>&gt;</FONT> =
><BR><FONT=20
>  size=3D2>&gt; Does this mean that a signature may be (before base 64=20
>  encoding):</FONT> <BR><FONT size=3D2>&gt;</FONT> <BR><FONT=20
>  size=3D2>&gt;&nbsp;&nbsp; SEQUENCE { SEQUENCE { OID . NULL } . =
>BIT_STRING {=20
>  SIGNATURE_VALUE } }</FONT> <BR><FONT size=3D2>&gt; or:</FONT> =
><BR><FONT=20
>  size=3D2>&gt;&nbsp;&nbsp; SEQUENCE { OID . NULL } . BIT_STRING { =
>SIGNATURE_VALUE=20
>  }</FONT> <BR><FONT size=3D2>&gt; or:</FONT> <BR><FONT =
>size=3D2>&gt;&nbsp;&nbsp;=20
>  SEQUENCE { OID . NULL } . SIGNATURE_VALUE</FONT> <BR><FONT =
>size=3D2>&gt;=20
>  or:</FONT> <BR><FONT size=3D2>&gt;&nbsp;&nbsp; OID . =
>SIGNATURE_VALUE</FONT>=20
>  <BR><FONT size=3D2>&gt;</FONT> <BR><FONT size=3D2>&gt; Or, is it =
>suggesting that=20
>  the OID _within_ the RSA signature</FONT> <BR><FONT size=3D2>&gt; =
>(before=20
>  crypting) is optional?</FONT> <BR><FONT size=3D2>&gt;</FONT> <BR><FONT =
>
>  size=3D2>&gt; Regardless, I think it adds options and thus confusion =
>and=20
>  thus</FONT> <BR><FONT size=3D2>&gt; deserves, perhaps, to be =
>eliminated..</FONT>=20
>  <BR><FONT size=3D2>&gt;</FONT> <BR><FONT size=3D2>&gt; merlin</FONT> =
><BR><FONT=20
>  size=3D2>&gt;</FONT> <BR><FONT size=3D2>&gt;</FONT> <BR><FONT =
>size=3D2>&gt;</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 GMT

This archive was generated by hypermail 2.2.0 + w3c-0.29 : Thursday, 13 January 2005 12:10:11 GMT