From owner-spki@c2.net Wed Nov 4 20:49:43 1998 Received: from blacklodge.c2.net (blacklodge.c2.net [208.139.36.35]) by lox.sandelman.ottawa.on.ca (8.8.7/8.8.8) with ESMTP id UAA14105; Wed, 4 Nov 1998 20:49:38 -0500 (EST) Received: (from majordom@localhost) by blacklodge.c2.net (8.8.8/8.7.3) id RAA24521 for spki-outgoing; Wed, 4 Nov 1998 17:15:16 -0800 (PST) From: "Kaelin Colclasure" To: Subject: Application inquiry Date: Wed, 4 Nov 1998 17:16:31 -0800 MIME-Version: 1.0 Message-ID: <001a01be0859$ecbfd8e0$5a2005cf@pepper.talarian.com> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA-1; boundary="----=_NextPart_000_0021_01BE0816.DD84E750" Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-spki@c2.net Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0021_01BE0816.DD84E750 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0019_01BE0816.DD4F7F70" ------=_NextPart_000_0019_01BE0816.DD4F7F70 Content-Type: multipart/alternative; boundary="----=_NextPart_001_001A_01BE0816.DD528CB0" ------=_NextPart_001_001A_01BE0816.DD528CB0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Greetings, I have been reviewing the SPKI drafts and trying to apply the concepts to a security model for SmartSockets (our message-oriented middleware product). I believe I have a fair grasp of the theory of operation, but I am wrestling with the practical considerations of implementing and deploying SPKI. I hope that I might impose upon the members of this list to help enlighten me... :-) First, my reading of the proposals would lead me to conclude that either a) authorization certificates are to be issued "on demand" when a user requires the authorization in question (and passes the scrutiny of the authorizing authority) or b) a user is likely to accumulate a fair number of authorization certificates, which she will have to store somewhere. SPKI could apparently support either model, but is one preferred over the other? For the sake of discussion, let's call the first alternative the "ticket" security model and the second the "pass" model. The pass model requires that certificates be stored somewhere. For existing applications like S/MIME this is typically on the user's local machine. But AFAIK there are no standards as to *where* on a machine a given users certificates might be found. (Well, Win32 has some standard certifate store functions-- but not other OSs.) Does SPKI presume that a common certificate store will eventually be widely supported? Or is it expected that each application will manage the storage of its own certificates, as is currently done? (If there is any work being done in this arena, I'd appreciate a pointer.) With the ticket model, the local storage requirements are alleviated. But how does the service that issues ticket certificates keep track of authorizations? Might it aggregate pass-style certificates acquired from other sources, acting as a central store for them? The second issue I'm grappling with is that "tuple reduction" combined with obtaining the necessary keys to validate all the signatures of the certificates involved in a particular access check is a non-trivial operation. Are we really to trust each individual application to implement this correctly? Or could this perhaps be delegated to a trusted service which implements checking in accordance with local policies? The novel advantages of SPKI are quite apparent to me, but of course the devil is in the details of implementation... --Kaelin Colclasure Chief Architect Talarian Corporation ------=_NextPart_001_001A_01BE0816.DD528CB0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Greetings,

I have been reviewing the SPKI drafts and trying to = apply the concepts to a security model for SmartSockets (our = message-oriented middleware product). I believe I have a fair grasp of = the theory of operation, but I am wrestling with the practical = considerations of implementing and deploying SPKI.

I hope that I might impose upon the members of this = list to help enlighten me... :-)

First, my reading of the proposals would lead me to = conclude that either a) authorization certificates are to be issued = "on demand" when a user requires the authorization in question = (and passes the scrutiny of the authorizing authority) or b) a user is = likely to accumulate a fair number of authorization certificates, which = she will have to store somewhere. SPKI could apparently support either = model, but is one preferred over the other?

For the sake of discussion, let's call the first = alternative the "ticket" security model and the second the = "pass" model.

The pass model requires that certificates be stored = somewhere. For existing applications like S/MIME this is typically on = the user's local machine. But AFAIK there are no standards as to *where* = on a machine a given users certificates might be found. (Well, Win32 has = some standard certifate store functions-- but not other OSs.) Does SPKI = presume that a common certificate store will eventually be widely = supported? Or is it expected that each application will manage the = storage of its own certificates, as is currently done? (If there is any = work being done in this arena, I'd appreciate a pointer.)

With the ticket model, the local storage requirements = are alleviated. But how does the service that issues ticket certificates = keep track of authorizations? Might it aggregate pass-style certificates = acquired from other sources, acting as a central store for = them?

The second issue I'm grappling with is that = "tuple reduction" combined with obtaining the necessary keys = to validate all the signatures of the certificates involved in a = particular access check is a non-trivial operation. Are we really to = trust each individual application to implement this correctly? Or could = this perhaps be delegated to a trusted service which implements checking = in accordance with local policies?

The novel advantages of SPKI are quite apparent to me, = but of course the devil is in the details of implementation...

--Kaelin Colclasure
  Chief Architect
  Talarian Corporation

------=_NextPart_001_001A_01BE0816.DD528CB0-- ------=_NextPart_000_0019_01BE0816.DD4F7F70 Content-Type: application/octet-stream; name="Kaelin Colclasure (E-mail).vcf" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="Kaelin Colclasure (E-mail).vcf" BEGIN:VCARD VERSION:2.1 N:Colclasure;Kaelin;;; FN:Kaelin Colclasure (E-mail) ORG:Talarian Corporation; TITLE:Chief Architect TEL;WORK;VOICE:(650) 965-8050 x.113 TEL;WORK;FAX:(650) 965-9077 ADR;WORK:;;333 Distel Circle;Los Altos;CA;94022-1404;United States of = America LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:333 Distel Circle=3D0D=3D0ALos = Altos, CA 94022-1404=3D0D=3D0AUnited States of Americ=3D a EMAIL;PREF;INTERNET:kaelin@talarian.com REV:19980620T193415Z END:VCARD ------=_NextPart_000_0019_01BE0816.DD4F7F70-- ------=_NextPart_000_0021_01BE0816.DD84E750 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFyzCCApEw ggH6oAMCAQICEQCcBEkuEgwJfe5G+5rmvN+qMA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMiBQdWJsaWMgUHJpbWFy eSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05NzEwMTMwMDAwMDBaFw0wMjEwMTMyMzU5NTla MEMxETAPBgNVBAoTCFZlcmlTaWduMS4wLAYDVQQLEyVWZXJpU2lnbiBDbGFzcyAyIE9uU2l0ZSBJ bmRpdmlkdWFsIENBMIGdMA0GCSqGSIb3DQEBAQUAA4GLADCBhwKBgQDcKpmdbjP8u0F2xDkejfd2 55APdFVhYXI8+DdLGx8I6TAdcMUWiWAzRkh/xtCaPXaYw6HBrFLRF7kUBGmGXGFPs2Vli2Oi7iF8 Qa+tckDDTZGzSb6Y+1fHWi6wS6fvCSTzgZ04xZLaSqeYUanYMHYtatavL37bESqF+2VgWkXoGwIB A6NrMGkwNgYDVR0gBC8wLTArBgtghkgBhvhFAQcBATAcMBoGCCsGAQUFBwIBBA5hYWFhYWFhYWFh YWFhYTAPBgNVHRMECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjARBglghkgBhvhCAQEEBAMCAQYwDQYJ KoZIhvcNAQECBQADgYEAcIT6yQbybtCfVyN2WEkBH/e6B4wilv3T5RNP4+gcocPBJpJM7h+w0VZa CBEN5vds3ZMhBVZDu+0I/epZ0cYBClDsdQLeqGI7EZmtKnlhex/xpRYEpj7cScVEYIROF0eU0yEz aDqE1BGzG3VIkGVFejWNe8B6tMZNCLQldDEJxIAwggMyMIICm6ADAgECAhBLT45KcpJLQUowhWcm ouaHMA0GCSqGSIb3DQEBBAUAMEMxETAPBgNVBAoTCFZlcmlTaWduMS4wLAYDVQQLEyVWZXJpU2ln biBDbGFzcyAyIE9uU2l0ZSBJbmRpdmlkdWFsIENBMB4XDTk4MDYyNTAwMDAwMFoXDTk5MDYyNTIz NTk1OVowgdkxHTAbBgNVBAoUFFRhbGFyaWFuIENvcnBvcmF0aW9uMRQwEgYDVQQLFAtFbmdpbmVl cmluZzFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L0NQUyBJbmNvcnAuIGJ5 IFJlZi4sTElBQi5MVEQoYyk5NjEYMBYGA1UEDBMPQ2hpZWYgQXJjaGl0ZWN0MRwwGgYDVQQDExNL YWVsaW4gTCBDb2xjbGFzdXJlMSIwIAYJKoZIhvcNAQkBFhNrYWVsaW5AdGFsYXJpYW4uY29tMFww DQYJKoZIhvcNAQEBBQADSwAwSAJBAOSBai9LMUll1Y+xWm7yfm9Yayiz7qFyljOrXPz3DsbyFljf 62RBJ3/Hc+ptMoePOutWwNAsVuNttNLrxm3N6h0CAwEAAaOB0zCB0DAJBgNVHRMEAjAAMIGvBgNV HSAEgacwgDCABgtghkgBhvhFAQcBATCAMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2ln bi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24n cyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbgAAAAAA ADARBglghkgBhvhCAQEEBAMCB4AwDQYJKoZIhvcNAQEEBQADgYEArACz7KYkNx+0wCdAcYGyqLih F7/8bdT4hyK93NKL0Tn/qsxHPbTWDr5ngwTZ/lG2m4CVnfDF/C7/b4Fd6EpGEb6DHd2th8h9j/3i RuSH/5cYv7uzvqE39zxV7PuLB3Ie7SE1/ONVKx/vr6Otw533apEPt5W66D0eHvSfAfJDWGExggHf MIIB2wIBATBXMEMxETAPBgNVBAoTCFZlcmlTaWduMS4wLAYDVQQLEyVWZXJpU2lnbiBDbGFzcyAy IE9uU2l0ZSBJbmRpdmlkdWFsIENBAhBLT45KcpJLQUowhWcmouaHMAkGBSsOAwIaBQCgggEfMBgG CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTk4MTEwNTAxMTYzMVowIwYJ KoZIhvcNAQkEMRYEFCCIiego97ucyuYdsJ0Ogjn434xKMFgGCSqGSIb3DQEJDzFLMEkwDgYIKoZI hvcNAwICAgCAMAoGCCqGSIb3DQMHMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoG CCqGSIb3DQIFMGYGCSsGAQQBgjcQBDFZMFcwQzERMA8GA1UEChMIVmVyaVNpZ24xLjAsBgNVBAsT JVZlcmlTaWduIENsYXNzIDIgT25TaXRlIEluZGl2aWR1YWwgQ0ECEEtPjkpykktBSjCFZyai5ocw DQYJKoZIhvcNAQEBBQAEQCziZ+iOhyo7JtcKBxmW97vabqfpqQjA2nKWJnNQ5xdkAIq2IuGlPkS6 Aujk1jZwxcufbVTOoql6ccjb7eP1VcsAAAAAAAA= ------=_NextPart_000_0021_01BE0816.DD84E750--