From owner-ietf-sacred@mail.imc.org Tue Jan 7 16:55:53 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00484 for ; Tue, 7 Jan 2003 16:55:53 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h07Ltpi01980 for ietf-sacred-bks; Tue, 7 Jan 2003 13:55:51 -0800 (PST) Received: from tholian.rsasecurity.com (tholian.rsasecurity.com [204.167.114.129]) by above.proper.com (8.11.6/8.11.3) with SMTP id h07Ltno01976 for ; Tue, 7 Jan 2003 13:55:49 -0800 (PST) Received: from no.name.available by tholian.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 7 Jan 2003 21:55:52 UT Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id QAA19744 for ; Tue, 7 Jan 2003 16:55:51 -0500 (EST) Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.10.2) with ESMTP id h07Lqkr01510 for ; Tue, 7 Jan 2003 16:52:46 -0500 (EST) Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id ; Tue, 7 Jan 2003 16:55:49 -0500 Received: from MNYSTROM-LAP ([10.3.9.2]) by exrsa01.rsa.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id Y760DCCC; Tue, 7 Jan 2003 13:55:41 -0800 From: "Nystrom, Magnus" Reply-To: "Nystrom, Magnus" To: ietf-sacred@imc.org Date: Tue, 7 Jan 2003 22:55:09 +0100 (W. Europe Standard Time) Subject: Working Group Last-Call on protocol I-D Message-ID: X-X-Sender: mnystrom@exrsa01.rsa.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: All, This is to announce that we now start a working group last-call on the protocol document, now in version -05. As I see it, there is only one unresolved issue - whether to add a DELETE message or not - but of course other things may turn up during this last call period, which will run until February 1st, 2003. -- Magnus From owner-ietf-sacred@mail.imc.org Tue Jan 7 17:32:19 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01514 for ; Tue, 7 Jan 2003 17:32:19 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h07MXfV04064 for ietf-sacred-bks; Tue, 7 Jan 2003 14:33:41 -0800 (PST) Received: from kalia.dbc.mtview.ca.us ([65.125.189.56]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h07MXeo04060 for ; Tue, 7 Jan 2003 14:33:40 -0800 (PST) Received: from kalia.dbc.mtview.ca.us (localhost [127.0.0.1]) by kalia.dbc.mtview.ca.us (8.12.6/8.12.6) with SMTP id h07MXVui003300; Tue, 7 Jan 2003 14:33:31 -0800 (PST) Date: Tue, 7 Jan 2003 14:33:31 -0800 From: Marshall Rose To: "Nystrom, Magnus" Cc: mnystrom@rsasecurity.com, ietf-sacred@imc.org Subject: Re: Working Group Last-Call on protocol I-D Message-Id: <20030107143331.64e00104.mrose@dbc.mtview.ca.us> In-Reply-To: References: Organization: Dover Beach Consulting, Inc. X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386-unknown-netbsdelf1.6) Mime-Version: 1.0 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 > This is to announce that we now start a working group last-call on the > protocol document, now in version -05. As I see it, there is only one > unresolved issue - whether to add a DELETE message or not - but of course > other things may turn up during this last call period, which will run > until February 1st, 2003. uh, could you wait until after the secretariat sends out the publication notice before making a last call? /mtr From owner-ietf-sacred@mail.imc.org Thu Jan 9 08:32:42 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08992 for ; Thu, 9 Jan 2003 08:32:42 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h09DXQ717251 for ietf-sacred-bks; Thu, 9 Jan 2003 05:33:26 -0800 (PST) Received: from tholian.rsasecurity.com (tholian.securitydynamics.com [204.167.114.129]) by above.proper.com (8.11.6/8.11.3) with SMTP id h09DXNo17238 for ; Thu, 9 Jan 2003 05:33:23 -0800 (PST) Received: from no.name.available by tholian.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 9 Jan 2003 13:33:27 UT Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id IAA28729 for ; Thu, 9 Jan 2003 08:33:25 -0500 (EST) Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.10.2) with ESMTP id h09DUKk28089 for ; Thu, 9 Jan 2003 08:30:20 -0500 (EST) Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id ; Thu, 9 Jan 2003 08:33:24 -0500 Received: from MNYSTROM-LAP ([10.129.13.146]) by exrsa01.rsa.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id Y760DF3J; Thu, 9 Jan 2003 05:33:13 -0800 From: "Nystrom, Magnus" Reply-To: "Nystrom, Magnus" To: ietf-sacred@imc.org Cc: Marshall Rose Date: Thu, 9 Jan 2003 14:32:40 +0100 (W. Europe Standard Time) Subject: Re: Working Group Last-Call on protocol I-D In-Reply-To: <20030107143331.64e00104.mrose@dbc.mtview.ca.us> Message-ID: References: <20030107143331.64e00104.mrose@dbc.mtview.ca.us> X-X-Sender: mnystrom@exrsa01.rsa.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Marshall suggests that we fix the broken Appendix B in -05, and then have a last call on -06 instead. Stephen and I agree. The working group last-call on -05 is therefore recalled and we will start a new last-call as soon as -06 has been published. -- Magnus On Tue, 7 Jan 2003, Marshall Rose wrote: > > This is to announce that we now start a working group last-call on the > > protocol document, now in version -05. As I see it, there is only one > > unresolved issue - whether to add a DELETE message or not - but of course > > other things may turn up during this last call period, which will run > > until February 1st, 2003. > > uh, could you wait until after the secretariat sends out the publication notice > before making a last call? From owner-ietf-sacred@mail.imc.org Mon Jan 27 06:47:46 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12686 for ; Mon, 27 Jan 2003 06:47:45 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0RBmFR01595 for ietf-sacred-bks; Mon, 27 Jan 2003 03:48:15 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0RBmEo01590 for ; Mon, 27 Jan 2003 03:48:14 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12567; Mon, 27 Jan 2003 06:44:43 -0500 (EST) Message-Id: <200301271144.GAA12567@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-sacred@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-sacred-protocol-bss-06.txt Date: Mon, 27 Jan 2003 06:44:43 -0500 Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Securely Available Credentials Working Group of the IETF. Title : Securely Available Credentials Protocol Author(s) : S. Farrell Filename : draft-ietf-sacred-protocol-bss-06.txt Pages : 23 Date : 2003-1-24 This document describes a protocol for the secure up- and down-load of cryptographic credentials. Discussion of this draft is taking place on the SACRED mailing list of the IETF SACRED working group (see http://www.imc.org/ietf-sacred for subscription information). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sacred-protocol-bss-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sacred-protocol-bss-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sacred-protocol-bss-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-1-24113253.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sacred-protocol-bss-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sacred-protocol-bss-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-1-24113253.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-sacred@mail.imc.org Mon Jan 27 08:52:40 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15862 for ; Mon, 27 Jan 2003 08:52:40 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0RDs5Y08975 for ietf-sacred-bks; Mon, 27 Jan 2003 05:54:05 -0800 (PST) Received: from tholian.rsasecurity.com (tholian.securitydynamics.com [204.167.114.129]) by above.proper.com (8.11.6/8.11.3) with SMTP id h0RDs3o08969 for ; Mon, 27 Jan 2003 05:54:03 -0800 (PST) Received: from no.name.available by tholian.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 27 Jan 2003 13:54:04 UT Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id IAA14571 for ; Mon, 27 Jan 2003 08:54:00 -0500 (EST) Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.10.2) with ESMTP id h0RDofv13186 for ; Mon, 27 Jan 2003 08:50:49 -0500 (EST) Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id ; Mon, 27 Jan 2003 08:53:46 -0500 Received: from MNYSTROM-LAP ([10.3.9.8]) by exrsa01.rsa.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DY28WLAS; Mon, 27 Jan 2003 05:53:41 -0800 From: "Nystrom, Magnus" Reply-To: "Nystrom, Magnus" To: ietf-sacred@imc.org Date: Mon, 27 Jan 2003 14:53:25 +0100 (W. Europe Standard Time) Subject: WG Last Call [Was: I-D ACTION:draft-ietf-sacred-protocol-bss-06.txt] In-Reply-To: <200301271144.GAA12567@ietf.org> Message-ID: References: <200301271144.GAA12567@ietf.org> X-X-Sender: mnystrom@exrsa01.rsa.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: All, Stephen has now fixed Appendix B and I therefore re-issue the working group last call on version -06 of this document. As I wrote previously, I see one unresolved issue at this point - whether to add a DELETE message or not, but of course other issues may turn up. The last call runs until February 21st, 2003. Regards, -- Magnus > All, > This is to announce that we now start a working group last-call on the > protocol document, now in version -05. As I see it, there is only one > unresolved issue - whether to add a DELETE message or not - but of > course other things may turn up during this last call period, which will > run until February 1st, 2003. On Mon, 27 Jan 2003 Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Securely Available Credentials Working Group of the IETF. > > Title : Securely Available Credentials Protocol > Author(s) : S. Farrell > Filename : draft-ietf-sacred-protocol-bss-06.txt > Pages : 23 > Date : 2003-1-24 > > This document describes a protocol for the secure up- and down-load > of cryptographic credentials. Discussion of this draft is taking > place on the SACRED mailing list of the IETF SACRED working group > (see http://www.imc.org/ietf-sacred for subscription information). > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-sacred-protocol-bss-06.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body of the message. > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-sacred-protocol-bss-06.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-sacred-protocol-bss-06.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > From owner-ietf-sacred@mail.imc.org Fri Jan 31 06:51:36 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04042 for ; Fri, 31 Jan 2003 06:51:35 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0VBo7B22852 for ietf-sacred-bks; Fri, 31 Jan 2003 03:50:07 -0800 (PST) Received: from tholian.rsasecurity.com (tholian.rsasecurity.com [204.167.114.129] (may be forged)) by above.proper.com (8.11.6/8.11.3) with SMTP id h0VBo5o22848 for ; Fri, 31 Jan 2003 03:50:05 -0800 (PST) Received: from no.name.available by tholian.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 31 Jan 2003 11:50:06 UT Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id GAA13781; Fri, 31 Jan 2003 06:50:05 -0500 (EST) Received: from exuk01.securid.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.10.2) with ESMTP id h0VBkpS00775; Fri, 31 Jan 2003 06:46:51 -0500 (EST) Received: by exuk01 with Internet Mail Service (5.5.2653.19) id ; Fri, 31 Jan 2003 11:54:57 -0000 Message-ID: <418A63CAEBF2D4118A1A00508BB1A0B802BB1045@exuk01> From: "Richards, Gareth" To: "'stephen.farrell@baltimore.ie'" Cc: ietf-sacred@imc.org Subject: RE: Credential DELETE Operation Date: Fri, 31 Jan 2003 11:54:56 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-sacred@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Stephen, Sorry for the delay in getting back to you on this. A simple form of DELETE request could be something like this: I think this would meet the requirements in section 3.3 of the framework: 1. The CredentialSelector identifies the credential to delete. 2. The LastModified is the optional fingerprint. A DELETE-ALL operation could be handled by having an empty request. The references to delete could be removed from the description of the UploadRequest by changing the first six paragraphs of section 2.2.1 as follows: 2.2.1 Credential Upload This operation REQUIRES mutual authentication. The purpose of this operation is to allow the client to deposit a credential with the server. The client sends an UploadRequest message to the server which can contain zero or one Credential. If a credential with the same credential selector field as in the UploadRequest, (a "matching" credential), already exists for the account, then that credential is replaced with the new credential from the UploadRequest. Otherwise a "new" credential is associated with that account. If no "matching" credential exists, the server returns an error. A new section would then be needed describing the new operation. 2.2.3 Credential Delete This operation REQUIRES mutual authentication. The purpose of this operation is to allow the client to delete one or more credentials associated with the account. The client sends an DeleteRequest message to the server which can contain zero or one CredentialSelector. If the UploadRequest contains no CredentialSelector then the all the credentials associated with that account are deleted. If no "matching" credential exists, the server returns an error. If the LastModified value is present in the DeleteRequest then it MUST be the value which was most recently received in a corresponding DownloadResponse for that credential. If the value does not match then the server MUST NOT delete the credentials. The server responds with an error or acknowledgement message. Dale raised the issue of unintentionally deleting all credentials but I'm not sure how much of a risk there is since the PDUs would not be created by the user's directly. > -----Original Message----- > From: Stephen Farrell [mailto:stephen.farrell@baltimore.ie] > Sent: 19 December 2002 12:16 > To: Richards, Gareth > Cc: ietf-sacred@imc.org > Subject: Re: Credential DELETE Operation > > > > Gareth, > > I do have some sympathy with this approach, but its somewhat late > in the day (for this rev of the I-D) to be making such a bigish > change given that we do have a working protocol (I don't think > you're saying it doesn't work as is) and don't have text for > the suggested change. > > So I'd be against making this change right now. > > During the last-call of the protocol draft (next rev > hopefully today!) > you can of course suggest this change *with specific text* > that implements > it (and I'd suggest waiting to base your text on the -05 I-D). > > At that stage we can take it on board or not, depending on the usual > things... > > Is that ok? > > Stephen. > > "Richards, Gareth" wrote: > > > > In the current ID, credentials are deleted using the UploadRequest. > > > > According to section 2.2.1: > > > > a) If the UploadRequest contains no Credential and the UploadRequest > > contains a "Delete="yes"" attribute, then the all the > credentials associated > > with that account are deleted. > > > > b) If the new credential from the UploadRequest contains no > PayLoad field > > and the new credential has a "Delete="yes"" attribute, then > the (one and > > only) "matching" credential is deleted. > > > > One minor point is that in the current schema the Payload > is not an optional > > element in the CredentialType and this appears to be > required to allow the > > second delete to occur. > > > > However, it may be simpler to implement the DELETE > operation described in > > Section 3.3 of the framework document with a separate > DeleteRequest rather > > than overloading the UploadRequest in the way described. > One possibility > > would be for the DeleteRequest PDU to be either empty or contain an > > CredentialSelector and optional LastModified. If it is > empty then it is a > > request to delete all credential otherwise it is a request > to delete a > > specific credential. > > > > This would have a number of advantages: > > > > 1) There would be no need to have a Delete attribute in the > CredentialType. > > > > 2) There would be no need to have an optional Payload since > the only time a > > Credential can meaningfully not contain a Payload is if the > Delete attribute > > is set to "yes" and it is contained in an UploadRequest. > > > > 3) The UploadRequest PDU could be simplified by removing the Delete > > attribute and making the Credential mandatory. > > > > 4) The conditions on the use UploadRequest given in section > 2.2.1 would be > > simplified. > > -- > ____________________________________________________________ > Stephen Farrell > Baltimore Technologies, tel: (direct line) +353 1 881 6716 > 39 Parkgate Street, fax: +353 1 881 7000 > Dublin 8. mailto:stephen.farrell@baltimore.ie > Ireland http://www.baltimore.com >