From owner-ipseckey-outgoing@lox.sandelman.ottawa.on.ca Mon Dec 16 12:26:51 2002 Received: (from majordom@localhost) by lox.sandelman.ottawa.on.ca (8.8.7/8.8.8) id MAA02914 for ipseckey-outgoing; Mon, 16 Dec 2002 12:26:51 -0500 (EST) Received: from noxmail.sandelman.ottawa.on.ca (nox.sandelman.ottawa.on.ca [192.139.46.6]) by lox.sandelman.ottawa.on.ca (8.8.7/8.8.8) with ESMTP id MAA02909 for ; Mon, 16 Dec 2002 12:26:49 -0500 (EST) Received: from sandelman.ottawa.on.ca (marajade.sandelman.ottawa.on.ca [192.139.46.20]) by noxmail.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id gBGHM4N00867 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Mon, 16 Dec 2002 12:22:11 -0500 (EST) Received: from sandelman.ottawa.on.ca (marajade [127.0.0.1]) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id gBGGNs3P002370 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for ; Mon, 16 Dec 2002 11:23:55 -0500 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id gBGGNskx002367 for ; Mon, 16 Dec 2002 11:23:54 -0500 Message-Id: <200212161623.gBGGNskx002367@sandelman.ottawa.on.ca> To: ipseckey@lox.sandelman.ottawa.on.ca Subject: [IPSECKEY] minutes from BOF Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Mon, 16 Dec 2002 11:23:53 -0500 From: Michael Richardson Sender: owner-ipseckey@sandelman.ottawa.on.ca Precedence: bulk X-List: ipseckey@sandelman.ottawa.on.ca Date: Sat, 14 Dec 2002 09:34:51 -0500 (EST) From: Sam Weiler IPSECKEY BOF at IETF-55 Atlanta 19 November 2002 Reported by Samuel Weiler Mailing list: ipseckey@sandelman.ottawa.on.ca To subscribe, put "subscribe ipseckey" in the body of a message to majordomo@sandleman.ottawa.on.ca Draft: draft-richardson-ipsec-rr-00.txt This is an effort to specify an RR to be used to distribute public keys and gateway addresses for opportunistic IPSEC, to replace the current use of both a TXT RR and a KEY RR. In years past, the DNS working groups were seen as being stingy with new RR type codes, so KEY was subtyped and used for both DNSSEC keys and application keys. A recent draft prohibits applications from using KEY. This is primarily an effort to replace the existing functionality, which requires a remote system's public RSA key and a IP address of it's gateway, both indexed by IP address. Scott Rose presented a synopsis of draft-ietf-dnsext-restrict-key-for-dnssec-04.txt, which prohibits applications from using the KEY RR to avoid large keysets at a zone apex, to avoid subtyping, and to separate administration of DNSSEC and application keys. He emphasized that the DNSSEC spec rewrite currently in progress does not forbid the use of DNS for storing application key material. There was some discussion of whether the problems the restrict-key draft purports to address are real. Subtyping is architecturally flawed -- DNS lookups are based on class/name/type, and there seemed to be widespread support for the idea that subtyping should be avoided. There was not consensus as to whether overflow to TCP, which is almost certain when you have application KEY RRs sharing a zone apex with DNSSEC KEYs, is _really_ problematic: application use of KEYs was not experimented with at previous workshops. Hugh Daniel expressed substantial frustration that the restrict-key draft seems to be going through before a replacement for use of the KEY RR is in place, especially given that there's deployed code using KEY for IPSEC. Steve Bellovin expressed great reluctance to hold up the DNSSEC spec to wait for this and pointed out that there isn't a protocol police -- no one is going to forcibly stop the use of KEY for IPSEC. There was much discussion of whether to focus on IPSEC keys or something more general. A more general BOF (SIKED) was held Minneapolis (March 2002), and the feedback from there was not to try to do everything at once and instead go for one protocol at a time. Furthermore, the trust model of each application (ie. S/MIME) may not match that of DNSSEC -- there are decisions that will have to be made per application. And the same logic that applied for evicting IPSEC from using KEY applies to reuse of an APPKEY RR type by multiple applications that will presumably need different additional/support data: subtyping is evil. Micheal presented an initial proposal for an IPSECKEY RR. It contains an extensible series of type-length-value tuples. Specific fields types would be: priority, v4/v6 addresses of gateway, FQDN of gateway, RSA key of gateway. There was some discussion of whether a hostname to key mapping (in the forward tree) would be more appropriate. The BOF chairs intend this effort to replace the existing functionality, which uses the reverse tree, and in order to have the naming model of this mapping match the IPSEC naming model, it's appropriate to use the reverse tree. A gateway needs to be specified because you may have boxes sitting behind an IPSEC gateway that need to delegate authority to make the IPSEC connections. The desired case is that nodes are their own gateways, in which case they list themselves or nothing as gateway. What if DNSSEC weren't available? You'd still be protected from some passive attacks, which has value. It is very easy to poison DNS caches, and while an active attack, it's not as difficult as a man-in-the-middle. A sample charter was presented with a single deliverable draft to published as soon as the queue opens with a final version in Jan/Feb and submission to the IESG in March. There was a noticeable hum in favor of requesting a WG with an IPSEC-specific charter and a timeline of six months. There was no noticeable hum when the room was asked if the effort was worthless. - This is the IPSECKEY@sandelman.ca list. Email to ipseckey-request@sandelman.ca to be removed. From owner-ipseckey-outgoing@lox.sandelman.ottawa.on.ca Mon Dec 16 13:31:03 2002 Received: (from majordom@localhost) by lox.sandelman.ottawa.on.ca (8.8.7/8.8.8) id NAA07421 for ipseckey-outgoing; Mon, 16 Dec 2002 13:31:03 -0500 (EST) Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by lox.sandelman.ottawa.on.ca (8.8.7/8.8.8) with ESMTP id NAA07416 for ; Mon, 16 Dec 2002 13:31:01 -0500 (EST) Received: from vhqpostal-gw2.verisign.com (verisign.com [65.205.251.56]) by peacock.verisign.com (8.12.1/) with ESMTP id gBGIPwkw028311 for ; Mon, 16 Dec 2002 10:25:58 -0800 (PST) Received: by vhqpostal-gw2.verisign.com with Internet Mail Service (5.5.2653.19) id ; Mon, 16 Dec 2002 10:26:21 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: ipseckey@lox.sandelman.ottawa.on.ca Subject: RE: [IPSECKEY] minutes from BOF Date: Mon, 16 Dec 2002 10:26:15 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=SHA1; boundary="----=_NextPart_000_0013_01C2A506.99865660"; protocol="application/x-pkcs7-signature" X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipseckey@sandelman.ottawa.on.ca Precedence: bulk X-List: ipseckey@sandelman.ottawa.on.ca This is a multi-part message in MIME format. ------=_NextPart_000_0013_01C2A506.99865660 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit I believe that I made a number of comments on the issue of DNS Key records and XKMS/SRV. I can't remember the exact points I raised, however the argument I have been advancing goes something like this: 1) Directory based and Directory linked PKI have failed because they are the wrong model and key off the wrong index. I differentiate Directory linked PKI and DNS linked PKI here because I believe that the reasons why Directory linked PKI has failled do not apply to DNS linkage. The main problem with using an LDAP or X.500 directory as the hub of an Internet PKI is that there is no X.500 infrastructure at that scale and there never will be. The DNS is the naming infrastructure of the Internet. The secondary problem is that the concept of the directory as the authoritative name source was simply wrong. Common names are not unique identifiers. RFC822 Email addresses are. 2) DNS is fragile, handle with care There have been numerous points raised about the straw that broke the DNS back problem. While I believe that we can probably make DNS work in whatever context we need to, the costs of doing so might be more than people are willing to bear. 3) DNS is not deployed as trusted cryptographic infrastructure So be very careful when layering cryptographic functions on top of it. 4) Real world PKI topologies are rarely hierarchies The DNS is an (the?) exception. However most application PKIs in which there are issues of liability, risk etc are not actually hierarchies, and if they are hierarchies the root is not ICANN or the ISOC or IETF. Real world PKI topologies tend to look hierarchical at the base of the tree and get web of trust-ish at the top. See the FBCA for an example. 5) Real world PKI at Internet scale requires separation of the key discovery and key validation processes PGP and S/MIME both fail at internet scale because of the problem of locating encryption keys. At present both PGP and S/MIME resort to out of band configuration to hand configured discovery mechanisms, often the users address book... 6) DNS Linked PKI is best model for most applications The model I have come to prefer for PKI is to make key management a separate function that is linked to the DNS, either via a SRV or NAPTR record. So if I have an email address fred@somewhere.com my email client follows an SRV record in the DNS zone somewhere.com to find a key discovery service for fred@somewhere.com. My overwhelming preference here is for the discovery service interface to be of the form used in XKMS 'give me a key to talk S/MIME to fred@somewhere.com'. If people want to they can try to make key discovery through LDAP directories work, however I think that model is broken since it is impossible to know what path to follow throught the Web of trust to locate the trust chain. Linking the PKI to DNS is preferable to merging PKI and DNS for many reasons, not least the fact that DNS is not designed as a PKI and DNSSEC is constantly having to work arround constraints due to the deployed base. 7) IPSEC is an exception IPSEC is different because at that level there is a precise alignment of the DNS hierarchy and the trust topology. 8) DNSSEC is needed to securely distribute policy The real value of DNSSEC is that it allows the secure distribution of the security policy for a zone to be communicated, either through records in the DNS itself or (preferred) by means of a link to a policy distribution mechanism. This allows downgrade attacks to be prevented. Consider the following policy statements: a) All mail in this zone is signed b) The SMTP mail server in this zone offers SSL Upgrade c) This host offers IPSEC connectivity Obtaining this type of policy information from an authoritative source is very powerful. For example a and b might be used to reject SPAM with a forged address from that zone - very powerful since much of the spam sent has a bogus from address to evade filters, a lot is forged as comming from the user meant to receive it. 9) Validation of keys is not an issue if the alternative is plaintext Most of the Internet mechanisms we use have become complex because we have got the problem of man in the middle wrapped arround the axles. So because we can't solve the man in the middle without infrastructure we end up sending information plaintext instead. I don't see this so much as opportunistic encryption as simply a low threshold for key validation. We will accept the minimal validation provided by an SRV record in non-authenticated DNS and a key returned by XKMS locate followed by the 'accept everything' validation procedure. I like the idea of opportunistic encryption, but not if it means that we end up accepting an infrastructure that is only good for opportunistic encryption when we can have an infrastructure that will operate at any policy level for the same price, perhaps less since DNS linked PKI does not have the baggage of legacy deployment of a critical infrastructure to cope with. There is no reason why we could not get an XKMS locate service written and make a single distribution containing both that and BIND. Phill > -----Original Message----- > From: Michael Richardson [mailto:mcr@sandelman.ottawa.on.ca] > Sent: Monday, December 16, 2002 11:24 AM > To: ipseckey@lox.sandelman.ottawa.on.ca > Subject: [IPSECKEY] minutes from BOF > > > > Date: Sat, 14 Dec 2002 09:34:51 -0500 (EST) > From: Sam Weiler > > IPSECKEY BOF at IETF-55 Atlanta > 19 November 2002 > Reported by Samuel Weiler > > Mailing list: ipseckey@sandelman.ottawa.on.ca > To subscribe, put "subscribe ipseckey" in the body of a message to > majordomo@sandleman.ottawa.on.ca > > Draft: draft-richardson-ipsec-rr-00.txt > > > This is an effort to specify an RR to be used to distribute public > keys and gateway addresses for opportunistic IPSEC, to replace the > current use of both a TXT RR and a KEY RR. In years past, the DNS > working groups were seen as being stingy with new RR type codes, so > KEY was subtyped and used for both DNSSEC keys and application keys. > A recent draft prohibits applications from using KEY. This is > primarily an effort to replace the existing functionality, which > requires a remote system's public RSA key and a IP address of it's > gateway, both indexed by IP address. > > Scott Rose presented a synopsis of > draft-ietf-dnsext-restrict-key-for-dnssec-04.txt, which prohibits > applications from using the KEY RR to avoid large keysets at a zone > apex, to avoid subtyping, and to separate administration of DNSSEC and > application keys. He emphasized that the DNSSEC spec rewrite > currently in progress does not forbid the use of DNS for storing > application key material. > > There was some discussion of whether the problems the restrict-key > draft purports to address are real. Subtyping is architecturally > flawed -- DNS lookups are based on class/name/type, and there seemed > to be widespread support for the idea that subtyping should be > avoided. There was not consensus as to whether overflow to TCP, > which is almost certain when you have application KEY RRs sharing a > zone apex with DNSSEC KEYs, is _really_ problematic: application use > of KEYs was not experimented with at previous workshops. > > Hugh Daniel expressed substantial frustration that the restrict-key > draft seems to be going through before a replacement for use of the > KEY RR is in place, especially given that there's deployed code using > KEY for IPSEC. Steve Bellovin expressed great reluctance to hold up > the DNSSEC spec to wait for this and pointed out that there isn't a > protocol police -- no one is going to forcibly stop the use of KEY for > IPSEC. > > There was much discussion of whether to focus on IPSEC keys or > something more general. A more general BOF (SIKED) was held > Minneapolis (March 2002), and the feedback from there was not to try > to do everything at once and instead go for one protocol at a time. > Furthermore, the trust model of each application (ie. S/MIME) may not > match that of DNSSEC -- there are decisions that will have to be made > per application. And the same logic that applied for evicting IPSEC > from using KEY applies to reuse of an APPKEY RR type by multiple > applications that will presumably need different additional/support > data: subtyping is evil. > > Micheal presented an initial proposal for an IPSECKEY RR. It contains > an extensible series of type-length-value tuples. Specific fields > types would be: priority, v4/v6 addresses of gateway, FQDN of gateway, > RSA key of gateway. There was some discussion of whether a hostname > to key mapping (in the forward tree) would be more appropriate. The > BOF chairs intend this effort to replace the existing functionality, > which uses the reverse tree, and in order to have the naming model of > this mapping match the IPSEC naming model, it's appropriate to use the > reverse tree. A gateway needs to be specified because you may have > boxes sitting behind an IPSEC gateway that need to delegate authority > to make the IPSEC connections. The desired case is that nodes are > their own gateways, in which case they list themselves or nothing as > gateway. > > What if DNSSEC weren't available? You'd still be protected from some > passive attacks, which has value. It is very easy to poison DNS > caches, and while an active attack, it's not as difficult as a > man-in-the-middle. > > A sample charter was presented with a single deliverable draft to > published as soon as the queue opens with a final version in Jan/Feb > and submission to the IESG in March. There was a noticeable hum in > favor of requesting a WG with an IPSEC-specific charter and a timeline > of six months. There was no noticeable hum when the room was asked if > the effort was worthless. > > > - > This is the IPSECKEY@sandelman.ca list. > Email to ipseckey-request@sandelman.ca to be removed. > ------=_NextPart_000_0013_01C2A506.99865660 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINbTCCAj0w 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+RWRMb7lKFIfSJDzKDGXHlV9WeBG2iYNCREsZjBOiheMIIEGTCCA4KgAwIBAgIQ da9pAn9XoMlLtvoUDq8LyTANBgkqhkiG9w0BAQQFADCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIElu Yy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJq ZWN0IHRvIHRlcm1zIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAj BgNVBAMTHFZlcmlTaWduIENsYXNzIDIgRW1wbG95ZWUgQ0EwHhcNMDIwMjI3MDAwMDAwWhcNMDMw MjI3MjM1OTU5WjBtMREwDwYDVQQKEwhWRVJJU0lHTjELMAkGA1UECxMCSFExEzARBgNVBAMTClJl Y2lwaWVudHMxNjA0BgNVBAMTLXBiYWtlciAoSGFsbGFtLUJha2VyIFBoaWxsaXAsIFZlcmlTaWdu LCBJbmMuKTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAtcA/okLsFi9brjmDsXQ6+g+R95B1 81Lq1EXkdzhY7XHxQ2QDq0sS2U4j9N1Ic6nHIiMq5dticztWpKdn6CrDx3Ovd5k+PACq/jSQo7NL tlMJi7fsUrP7pM4izKu4JjSak6wRJUA4x85TSC1PLfd1u8oq16iqNJRhpEJ8VJUMRyECAwEAAaOC AXgwggF0MAkGA1UdEwQCMAAwWQYDVR0fBFIwUDBOoEygSoZIaHR0cDovL29uc2l0ZWNybC52ZXJp c2lnbi5jb20vVmVyaVNpZ25JbmNFeGNoYW5nZUVtcGxveWVlcy9MYXRlc3RDUkwuY3JsMAsGA1Ud DwQEAwIFoDAeBgNVHREEFzAVgRNwYmFrZXJAdmVyaXNpZ24uY29tMIGsBgNVHSAEgaQwgaEwgZ4G C2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BT MGIGCCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEE BAMCB4AwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMA0GCSqGSIb3DQEBBAUAA4GBACCK +gbdTcJB2wmWF5q8hbnP6slvVFehmjSX1Se+4Ff6a3Uiw8aOQLyNwnYUSOtHe12rTwAtWOhEgXHK D4XY3tF7cofo5hM8dk8xsj9vV3z3fYARDr4nR2bZblPJ3MGmAFAYKW4pgX4Y6NU4VhAG2Hiuj18/ H4Cc5g5oqJp5dArUMYIC+DCCAvQCAQEwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0 byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQD ExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhB1r2kCf1egyUu2+hQOrwvJMAkGBSsOAwIa BQCgggGMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTIxNjE4 MjUyOFowIwYJKoZIhvcNAQkEMRYEFCHgBqFgNqPIHUgPKwNE0/a6eHHsMFgGCSqGSIb3DQEJDzFL MEkwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcG BSsOAwIaMAoGCCqGSIb3DQIFMIHSBgkrBgEEAYI3EAQxgcQwgcEwgawxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2Ug aXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChj KTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhB1r2kCf1egyUu2+hQO rwvJMA0GCSqGSIb3DQEBAQUABIGAD6uw+U4HprWUcy93bat68UR+rFVb3ZM+ADSIitMrMSRjYF6F vxcR+PJ04x+wN8gibR0+I9mmsmnK/o9wPC+j3eCkKUh+frq8FVQ0djKDo0MwIhgETVx9e9Z5P+S7 n4xDb2PMtPiP9iwTUN5c0199ajvciqMXooqpawGABx2qEQYAAAAAAAA= ------=_NextPart_000_0013_01C2A506.99865660-- - This is the IPSECKEY@sandelman.ca list. Email to ipseckey-request@sandelman.ca to be removed.