From owner-ietf-sacred@mail.imc.org Tue Oct 24 17:27:28 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA14307 for ; Tue, 24 Oct 2000 17:27:27 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id OAA14596 for ietf-sacred-bks; Tue, 24 Oct 2000 14:04:24 -0700 (PDT) Received: from balinese.baltimore.ie (firewall-user@pc215-8.indigo.ie [194.125.215.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA14592 for ; Tue, 24 Oct 2000 14:04:21 -0700 (PDT) Received: by balinese.baltimore.ie; id WAA29776; Tue, 24 Oct 2000 22:10:01 +0100 (GMT/IST) Received: from bobcat.ie.baltimore.com(10.153.25.10) by balinese.baltimore.ie via smap (V4.2) id xma029772; Tue, 24 Oct 00 22:09:28 +0100 Received: from baltimore.ie (wks114-25.ie.baltimore.com [10.153.25.114]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id WAA08640 for ; Tue, 24 Oct 2000 22:09:26 +0100 Message-ID: <39F5FB69.C2A85AB2@baltimore.ie> Date: Tue, 24 Oct 2000 22:13:13 +0100 From: Stephen Farrell Reply-To: stephen.farrell@baltimore.ie Organization: Baltimore Technologies Ltd. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-sacred Subject: we're official... Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Hi All, We're now an official WG. Charter page is at: http://www.ietf.org/html.charters/sacred-charter.html Stephen. BTW: Still calling for volunteers for the framework draft! Go on - don't be shy! -- ____________________________________________________________ Stephen Farrell Baltimore Technologies, tel: (direct line) +353 1 647 7406 61 Fitzwilliam Lane, fax: +353 1 647 7499 Dublin 2. mailto:stephen.farrell@baltimore.ie Ireland http://www.baltimore.com From owner-ietf-sacred@mail.imc.org Fri Oct 27 10:46:23 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA13923 for ; Fri, 27 Oct 2000 10:46:22 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id HAA01332 for ietf-sacred-bks; Fri, 27 Oct 2000 07:20:00 -0700 (PDT) Received: from balinese.baltimore.ie (firewall-user@pc215-8.indigo.ie [194.125.215.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA01328 for ; Fri, 27 Oct 2000 07:19:58 -0700 (PDT) Received: by balinese.baltimore.ie; id PAA25065; Fri, 27 Oct 2000 15:25:50 +0100 (GMT/IST) Received: from bobcat.ie.baltimore.com(10.153.25.10) by balinese.baltimore.ie via smap (V4.2) id xma024847; Fri, 27 Oct 00 15:24:56 +0100 Received: from baltimore.ie (ip203-221.ie.baltimore.com [192.168.21.203]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id PAA02576 for ; Fri, 27 Oct 2000 15:24:56 +0100 Message-ID: <39F9911E.E786BB1E@baltimore.ie> Date: Fri, 27 Oct 2000 15:28:46 +0100 From: Stephen Farrell Reply-To: stephen.farrell@baltimore.ie Organization: Baltimore Technologies Ltd. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-sacred Subject: enrollment/mgt operations Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Hi All, I'm looking through the comments we got on the requirements and would like to get some opinions about how much detail to include (in the requirments document) about management operations. Right now, there's just a generic requirement that the protocols must support mgt operations. Self-enrollment was mentioned on the list and should at least get a mention too. I guess the overall list of operations might be something like: GET for downloads from a CS PUT to update/change a credential or direct transfer one ENROLL could be a special case of PUT? DELETE to zap a credential (carefully:-) So, questions: - Should the requirements document specify these separately, each with associated MUSTs etc? - If yes, then what other management operations might there be? (e.g. do we need an interoperable form of DISABLE/ENABLE to temporarily make credentials unavailable, MODIFY to change an existing credential...) - Does all this just apply to the credential server case, or also for direct transfers? Regards, Stephen. BTW: Dale and Magnus have taken on drafting a framework document (thanks guys:-) so we should have one to discuss in San Diego if they manage to make the cutoff. -- ____________________________________________________________ Stephen Farrell Baltimore Technologies, tel: (direct line) +353 1 647 7406 61 Fitzwilliam Lane, fax: +353 1 647 7499 Dublin 2. mailto:stephen.farrell@baltimore.ie Ireland http://www.baltimore.com From owner-ietf-sacred@mail.imc.org Sun Oct 29 17:27:43 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA09454 for ; Sun, 29 Oct 2000 17:27:42 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id NAA01748 for ietf-sacred-bks; Sun, 29 Oct 2000 13:58:02 -0800 (PST) Received: from stargate.zergo.com.au (IDENT:root@stargate.zergo.com.au [203.2.208.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA01744 for ; Sun, 29 Oct 2000 13:57:59 -0800 (PST) Received: from sydneymail1.baltimore.com.au (sydneymail1.jp.zergo.com.au [192.168.71.5]) by stargate.zergo.com.au (8.9.1/8.8.7) with ESMTP id JAA18856; Mon, 30 Oct 2000 09:10:29 +1100 Received: by sydneymail1.jp.zergo.com.au with Internet Mail Service (5.5.2650.21) id ; Mon, 30 Oct 2000 10:02:37 +1100 Message-ID: From: Carlos Sotomayor To: stephen.farrell@baltimore.ie, ietf-sacred Subject: RE: enrollment/mgt operations Date: Mon, 30 Oct 2000 10:02:27 +1100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I think there should be some clarification of the management issues. Some queries I have are ... Are there plans to provide delegated credential access. An example could be that a manager could be given access to the team members credentials or a secretary could read and decrypt mail for the person they work for. Also there should be the ability to make an entity a retrieval authority such as a system admin or high ranking company employee. Also what about scenarios of revoking access to credentials for an entity but still allow the credential to be retrieved by another entity or authority. This could happen in a company when an employee leaves the company but their correspondence still needs to be accessible by an existing member of the company. Registering a new entity onto the system may warrant its own function. Many things could be configured at this point such as authentication method for that entity and also it provides a point at which an admin person can actually reject or allow an entity access to the system. There might be other situations where there already exists a compant entity registration database which is to be reused so the user registration will not neccessarily happen on the first credential upload. -----Original Message----- From: Stephen Farrell [mailto:stephen.farrell@baltimore.ie] Sent: Saturday, 28 October 2000 0:29 To: ietf-sacred Subject: enrollment/mgt operations Hi All, I'm looking through the comments we got on the requirements and would like to get some opinions about how much detail to include (in the requirments document) about management operations. Right now, there's just a generic requirement that the protocols must support mgt operations. Self-enrollment was mentioned on the list and should at least get a mention too. I guess the overall list of operations might be something like: GET for downloads from a CS PUT to update/change a credential or direct transfer one ENROLL could be a special case of PUT? DELETE to zap a credential (carefully:-) So, questions: - Should the requirements document specify these separately, each with associated MUSTs etc? - If yes, then what other management operations might there be? (e.g. do we need an interoperable form of DISABLE/ENABLE to temporarily make credentials unavailable, MODIFY to change an existing credential...) - Does all this just apply to the credential server case, or also for direct transfers? Regards, Stephen. BTW: Dale and Magnus have taken on drafting a framework document (thanks guys:-) so we should have one to discuss in San Diego if they manage to make the cutoff. -- ____________________________________________________________ Stephen Farrell Baltimore Technologies, tel: (direct line) +353 1 647 7406 61 Fitzwilliam Lane, fax: +353 1 647 7499 Dublin 2. mailto:stephen.farrell@baltimore.ie Ireland http://www.baltimore.com From owner-ietf-sacred@mail.imc.org Mon Oct 30 08:00:21 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA12798 for ; Mon, 30 Oct 2000 08:00:21 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id EAA27542 for ietf-sacred-bks; Mon, 30 Oct 2000 04:41:15 -0800 (PST) Received: from msw.mimesweeper.com (mail.mimesweeper.com [194.168.91.82]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA27537 for ; Mon, 30 Oct 2000 04:41:13 -0800 (PST) Received: from mswctl1.mimesweeper.com (unverified) by msw.mimesweeper.com (Content Technologies SMTPRS 4.1.5) with ESMTP id for ; Mon, 30 Oct 2000 12:47:29 +0000 Received: from BELL.mimesweeper.com (unverified) by mswctl2.mimesweeper.com (Content Technologies SMTPRS 4.2.0) with ESMTP id for ; Mon, 30 Oct 2000 12:46:47 +0000 Received: from GK-VAIO.Dial.pipex.com (gk-vaio.mimesweeper.com [194.168.90.137]) by BELL.mimesweeper.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id VVV0NYPM; Mon, 30 Oct 2000 12:44:59 -0000 Message-Id: <4.3.2.7.2.20001006120727.00ab0ee0@pop.dial.pipex.com> X-Sender: xex41@pop.dial.pipex.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 06 Oct 2000 12:46:19 +0100 To: ietf-sacred From: Graham Klyne Subject: Comments on draft-arsenault-sacred-reqs-00.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Folks, I offer the following observations for your consideration. They consist mostly of presentational nits. General: I noticed a few instances of a non-ASCII character being used where (I assume) an apostrophe (') was intended. E.g. "Mimi?s" in section 2.1. Abstract: I think it would be helpful for the first paragraph to mention mobility of credentials in some way. E.g. This document describes requirements to be placed on Securely Available Credentials (sacred) mobility protocols. Section 1, final para: I have found that the RFC2119 keywords, designed as they are for describing protocols, don't always work well when describing _requirements_ on protocols. For example, I'm not sure exactly what is meant by requirements G9, S4: are these saying the "protocol specification MAY define...", or that the protocol must be specified in a way such that "protocol implementations MAY..."? An alternative approach to describing protocol requirements levels can be found in RFC 2542, section 1.1. Section 1.1, 2nd para: When reading this, it occurred to me that having Mimi keep credentials on her computer was also not really very secure. I'm not sure if it's worth saying anything about this -- maybe properly managed mobile credentials would be _more_ secure. Or, to put it another way, is it possible that the sacred framework would help to protect credentials on a single system (regarding the transfer between long-term storage and immediate use as a kind of movement of credentials)? Section 1.2: How does the secure transfer of credentials between devices differ from the secure transfer of *any* sensitive information? (A clear answer to that question might help to convey the essence of this effort.) Section 2: Starting to read this, it seems to consist of background material as much as requirements. I would suggest that the pedagogical background material (which I think is very useful) be separated from the specific requirements. Section 2.1, page 5, final para (bullet 2): You say the credential server "may" have to be trusted... Is this strong enough? Otherwise, why not use any old web server? Section 2.1, page 6, 1st 2 paras: I found the first paragraph confusing, and the second paragraph to be rather laboured (though it did clear up my confusion). In general, I think the idea of a "direct" transfer as described is already implicit in the way Internet applications and protocols work. Thus, I think the two paragraphs could be replaced by: Thus, some users may prefer a different class of solution, in which credentials are transferred directly from one device to another (i.e. having no intermediary element that processes or has any understanding of the credentials). Section 2.2, requirement F3: I think the "which" here should be "that". Section 2.4, editorial comment: IMXP might be a candidate, suitable to a range of operating environments. Section 3.1, requirement G3: Is SHOULD strong enough? I'd have thought this is a MUST. Section 3.1, requirement G6: is this "MUST support the use of ..." or "MUST support the transfer of ..." Section 3.1, requirement G9: Section 3.2, requirement S4: I'm not sure what MAY means in these contexts (see earlier comment) Section 3.1, requirement G10: There's more to full I18N than charset use. Also language tagging for human readable text. Section 3.1, requirement G12: Privacy from whom? For example, it seems to me the client must be identified to somebody if credentials are transferred only to properly authorized recipients. Section 4, item "Vulnerabilities:" Should the framework specification not include some kind of trust model? -- That's all. #g ------------ Graham Klyne (GK@ACM.ORG)