From owner-ietf-sacred@mail.imc.org Mon Feb 3 09:49:07 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 JAA08930 for ; Mon, 3 Feb 2003 09:49:07 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h13EmnV25354 for ietf-sacred-bks; Mon, 3 Feb 2003 06:48:49 -0800 (PST) Received: from ocasey.baltimore.com (ocasey.baltimore.com [193.41.17.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h13Emld25349 for ; Mon, 3 Feb 2003 06:48:47 -0800 (PST) Received: from Baltimore-FW1 ([172.19.1.1]) by ocasey.baltimore.com (8.11.6/8.9.3) with SMTP id h13EbPA11137 for ; Mon, 3 Feb 2003 14:37:25 GMT Received: from ([10.153.25.53]) by Baltimore-FW1; Mon, 03 Feb 2003 14:45:01 +0000 (GMT) Received: from Baltimore-FW1 (wilde-i-1.ie.baltimore.com) by emeairlsw1.baltimore.com (Content Technologies SMTPRS 4.2.5) with SMTP id for ; Mon, 3 Feb 2003 14:39:58 +0000 Received: from ([10.153.25.10]) by Baltimore-FW1; Mon, 03 Feb 2003 14:44:59 +0000 (GMT) Received: from baltimore.ie (wks183-25.ie.baltimore.com [10.153.25.183]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id OAA09351; Mon, 3 Feb 2003 14:48:39 GMT Message-ID: <3E3E812A.79D7DD11@baltimore.ie> Date: Mon, 03 Feb 2003 14:48:10 +0000 From: Stephen Farrell Reply-To: stephen.farrell@baltimore.ie Organization: Baltimore Technologies Ltd. X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "Richards, Gareth" CC: ietf-sacred@imc.org Subject: Re: Credential DELETE Operation References: <418A63CAEBF2D4118A1A00508BB1A0B802BB1045@exuk01> 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 Gareth, I guess I'd still have my earlier gut reaction that since its late in the day and we don't absolutely need to make the change, I'd be against doing it (though not at all vehemently). If I had to offer a technical argument against this I'd say that we're just adding more error cases to the server, which is therfore less likely to interop smoothly with diverse clients (not that that's a winning argument in this case, I agree - OTOH, I don't see a winning argument for making this change either, so we're even:-). If others want to add the explicit delete message then please say so and once we know the concensus we'll work it in or not as the case may be. Meanwhile, if we did make this change, where'd be the text that tells the server what to do when it gets an UploadRequest containing zero credentials? Secondly, if we were making this change, I'd argue that we include an explicit "delete-all" rather then a sort-of-implicit one as below. Stephen. "Richards, Gareth" wrote: > > 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 > > -- ____________________________________________________________ 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 From owner-ietf-sacred@mail.imc.org Mon Feb 3 10:07: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 KAA09700 for ; Mon, 3 Feb 2003 10:07:45 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h13F8Ka25858 for ietf-sacred-bks; Mon, 3 Feb 2003 07:08:20 -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 h13F8Jd25849 for ; Mon, 3 Feb 2003 07:08:19 -0800 (PST) Received: from no.name.available by tholian.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 3 Feb 2003 15:08:21 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 KAA03959; Mon, 3 Feb 2003 10:08:20 -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 h13F50K03288; Mon, 3 Feb 2003 10:05:01 -0500 (EST) Received: by exuk01 with Internet Mail Service (5.5.2653.19) id ; Mon, 3 Feb 2003 15:13:09 -0000 Message-ID: <418A63CAEBF2D4118A1A00508BB1A0B802BB1052@exuk01> From: "Richards, Gareth" To: "'stephen.farrell@baltimore.ie'" Cc: ietf-sacred@imc.org Subject: RE: Credential DELETE Operation Date: Mon, 3 Feb 2003 15:13:02 -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, > > Meanwhile, if we did make this change, where'd be the text that > tells the server what to do when it gets an UploadRequest > containing zero credentials? I would think that if we do have a DeleteRequest then there is no need to allow an empty UploadRequest and so the start of section 2.2.1 could be: 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 MUST contain one Credential. The schema could then be: > > Stephen. > > "Richards, Gareth" wrote: > > > > Stephen, > > > > Sorry for the delay in getting back to you on this. > > > > A simple form of DELETE request could be something like this: > > > > > > > > > > > > maxOccurs="1"/> > > > > > > > > > > > > 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 > > > > > -- > ____________________________________________________________ > 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 > From owner-ietf-sacred@mail.imc.org Mon Feb 3 10:45:56 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 KAA10834 for ; Mon, 3 Feb 2003 10:45:55 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h13FhTX27645 for ietf-sacred-bks; Mon, 3 Feb 2003 07:43:29 -0800 (PST) Received: from sccrmhc03.attbi.com (sccrmhc03.attbi.com [204.127.202.63]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h13FhPd27641 for ; Mon, 3 Feb 2003 07:43:25 -0800 (PST) Received: from attbi.com (c-66-41-28-164.mn.client2.attbi.com[66.41.28.164]) by sccrmhc03.attbi.com (sccrmhc03) with SMTP id <2003020315432100300jt26ce>; Mon, 3 Feb 2003 15:43:21 +0000 Message-ID: <3E3E8E1D.AECBB212@attbi.com> Date: Mon, 03 Feb 2003 09:43:25 -0600 From: Dale Gustafson X-Mailer: Mozilla 4.78 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: stephen.farrell@baltimore.ie CC: "Richards, Gareth" , ietf-sacred@imc.org Subject: Re: Credential DELETE Operation References: <418A63CAEBF2D4118A1A00508BB1A0B802BB1045@exuk01> <3E3E812A.79D7DD11@baltimore.ie> 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 Stephen, I'm also in favor of adding a DELETE message at this time. Agree with your suggestion to define a specific DELETE-ALL message. Best Regards, Dale Gustafson Stephen Farrell wrote: > Hi Gareth, > > I guess I'd still have my earlier gut reaction that since its > late in the day and we don't absolutely need to make the change, > I'd be against doing it (though not at all vehemently). If I > had to offer a technical argument against this I'd say that we're > just adding more error cases to the server, which is therfore less > likely to interop smoothly with diverse clients (not that that's > a winning argument in this case, I agree - OTOH, I don't see a > winning argument for making this change either, so we're even:-). > > If others want to add the explicit delete message then please say > so and once we know the concensus we'll work it in or not as the > case may be. > > Meanwhile, if we did make this change, where'd be the text that > tells the server what to do when it gets an UploadRequest > containing zero credentials? Secondly, if we were making this > change, I'd argue that we include an explicit "delete-all" > rather then a sort-of-implicit one as below. > > Stephen. > > "Richards, Gareth" wrote: > > > > 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 > > > > > -- > ____________________________________________________________ > 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 From owner-ietf-sacred@mail.imc.org Mon Feb 3 11:05:32 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 LAA11499 for ; Mon, 3 Feb 2003 11:05:32 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h13G4ws00741 for ietf-sacred-bks; Mon, 3 Feb 2003 08:04:58 -0800 (PST) Received: from ocasey.baltimore.com (ocasey.baltimore.com [193.41.17.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h13G4td00733 for ; Mon, 3 Feb 2003 08:04:56 -0800 (PST) Received: from Baltimore-FW1 ([172.19.1.1]) by ocasey.baltimore.com (8.11.6/8.9.3) with SMTP id h13FrcA13392 for ; Mon, 3 Feb 2003 15:53:38 GMT Received: from ([10.153.25.53]) by Baltimore-FW1; Mon, 03 Feb 2003 16:01:15 +0000 (GMT) Received: from Baltimore-FW1 (wilde-i-1.ie.baltimore.com) by emeairlsw1.baltimore.com (Content Technologies SMTPRS 4.2.5) with SMTP id for ; Mon, 3 Feb 2003 15:56:11 +0000 Received: from ([10.153.25.10]) by Baltimore-FW1; Mon, 03 Feb 2003 16:01:12 +0000 (GMT) Received: from baltimore.ie (wks183-25.ie.baltimore.com [10.153.25.183]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id QAA10801; Mon, 3 Feb 2003 16:04:52 GMT Message-ID: <3E3E9307.FDD1D996@baltimore.ie> Date: Mon, 03 Feb 2003 16:04:23 +0000 From: Stephen Farrell Reply-To: stephen.farrell@baltimore.ie Organization: Baltimore Technologies Ltd. X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "Richards, Gareth" CC: ietf-sacred@imc.org Subject: Re: Credential DELETE Operation References: <418A63CAEBF2D4118A1A00508BB1A0B802BB1052@exuk01> 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 If we adopt the new message, that'd make more sense. What about making delete-all explicit? I assume you'd agree with that too? How'd you want that done? Stephen. "Richards, Gareth" wrote: > > Stephen, > > > > > Meanwhile, if we did make this change, where'd be the text that > > tells the server what to do when it gets an UploadRequest > > containing zero credentials? > > I would think that if we do have a DeleteRequest then there is no need to > allow an empty UploadRequest and so the start of section 2.2.1 could be: > > 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 MUST > contain one Credential. > > The schema could then be: > > > > > > > > > > > > > Stephen. > > > > "Richards, Gareth" wrote: > > > > > > Stephen, > > > > > > Sorry for the delay in getting back to you on this. > > > > > > A simple form of DELETE request could be something like this: > > > > > > > > > > > > > > > > > > > maxOccurs="1"/> > > > > > > > > > > > > > > > > > > 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 > > > > > > > > -- > > ____________________________________________________________ > > 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 > > -- ____________________________________________________________ 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 From owner-ietf-sacred@mail.imc.org Mon Feb 3 18:31:50 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 SAA25279 for ; Mon, 3 Feb 2003 18:31:49 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h13NUD015966 for ietf-sacred-bks; Mon, 3 Feb 2003 15:30:13 -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 h13NUBd15962 for ; Mon, 3 Feb 2003 15:30:11 -0800 (PST) Received: from no.name.available by tholian.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 3 Feb 2003 23:30:14 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 SAA15070 for ; Mon, 3 Feb 2003 18:30:13 -0500 (EST) Received: from exrsa01.rsa.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.10.2) with ESMTP id h13NQf610578 for ; Mon, 3 Feb 2003 18:26:41 -0500 (EST) Received: by exrsa01.rsa.com with Internet Mail Service (5.5.2653.19) id ; Mon, 3 Feb 2003 15:29:52 -0800 Received: from dhcp-pool02.local.aus.rsa.com (MNYSTROM-LAP [10.177.1.236]) by exrsa01.rsa.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DY28WZKA; Mon, 3 Feb 2003 15:29:44 -0800 From: "Nystrom, Magnus" Reply-To: "Nystrom, Magnus" To: Stephen Farrell Cc: "Richards, Gareth" , ietf-sacred@imc.org Date: Tue, 4 Feb 2003 09:29:23 +1000 (E. Australia Standard Time) Subject: Re: Credential DELETE Operation In-Reply-To: <3E3E9307.FDD1D996@baltimore.ie> Message-ID: References: <418A63CAEBF2D4118A1A00508BB1A0B802BB1052@exuk01> <3E3E9307.FDD1D996@baltimore.ie> X-X-Sender: mnystrom@[10.81.217.7] 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: Stephen, FWIW, I am obviously also in favor of having a DELETE message. It makes the protocol cleaner, and matches better against the framework document which actually defined "DELETE" as a basic operation. Gareth has listed a number of advantages of this change in his first email below. For the explicit "delete-all", could you explain why you suggest this? I can't see that it is to avoid "unintended" delete-all, since the client could just as well happen to send an explicit delete-all as sending an implicit one - it all happens under the hood anyway, and I would assume that a well-behaving client would require the user to do something explicit in order to delete all his/her credentials. -- Magnus On Mon, 3 Feb 2003, Stephen Farrell wrote: > > > If we adopt the new message, that'd make more sense. > > What about making delete-all explicit? I assume you'd agree with > that too? How'd you want that done? > > Stephen. > > "Richards, Gareth" wrote: > > > > Stephen, > > > > > > > > Meanwhile, if we did make this change, where'd be the text that > > > tells the server what to do when it gets an UploadRequest > > > containing zero credentials? > > > > I would think that if we do have a DeleteRequest then there is no need to > > allow an empty UploadRequest and so the start of section 2.2.1 could be: > > > > 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 MUST > > contain one Credential. > > > > The schema could then be: > > > > > > > > > > > > > > > > > > > > > > > > Stephen. > > > > > > "Richards, Gareth" wrote: > > > > > > > > Stephen, > > > > > > > > Sorry for the delay in getting back to you on this. > > > > > > > > A simple form of DELETE request could be something like this: > > > > > > > > > > > > > > > > > > > > > > > > > > maxOccurs="1"/> > > > > > > > > > > > > > > > > > > > > > > > > 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 > > > > > > > > > > > -- > > > ____________________________________________________________ > > > 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 > > > > > -- > ____________________________________________________________ > 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 > From owner-ietf-sacred@mail.imc.org Tue Feb 4 06:35:21 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 GAA16648 for ; Tue, 4 Feb 2003 06:35:21 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h14Bad601649 for ietf-sacred-bks; Tue, 4 Feb 2003 03:36:39 -0800 (PST) Received: from ocasey.baltimore.com (ocasey.baltimore.com [193.41.17.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h14Babd01645 for ; Tue, 4 Feb 2003 03:36:37 -0800 (PST) Received: from Baltimore-FW2 ([172.19.1.2]) by ocasey.baltimore.com (8.11.6/8.9.3) with SMTP id h14BPDA04088 for ; Tue, 4 Feb 2003 11:25:13 GMT Received: from ([10.153.25.53]) by Baltimore-FW2; Tue, 04 Feb 2003 11:34:49 +0000 (GMT) Received: from Baltimore-FW2 (wilde-i-2.ie.baltimore.com) by emeairlsw1.baltimore.com (Content Technologies SMTPRS 4.2.5) with SMTP id for ; Tue, 4 Feb 2003 11:27:50 +0000 Received: from ([10.153.25.10]) by Baltimore-FW2; Tue, 04 Feb 2003 11:34:45 +0000 (GMT) Received: from baltimore.ie (wks186-25.ie.baltimore.com [10.153.25.186]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id LAA23289; Tue, 4 Feb 2003 11:36:31 GMT Message-ID: <3E3FA5A2.87658DF@baltimore.ie> Date: Tue, 04 Feb 2003 11:36:02 +0000 From: Stephen Farrell Reply-To: stephen.farrell@baltimore.ie Organization: Baltimore Technologies Ltd. X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "Nystrom, Magnus" CC: "Richards, Gareth" , ietf-sacred@imc.org Subject: Re: Credential DELETE Operation References: <418A63CAEBF2D4118A1A00508BB1A0B802BB1052@exuk01> <3E3E9307.FDD1D996@baltimore.ie> 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 Magnus, > For the explicit "delete-all", could you explain why you suggest this? Merely applying blind logic to the situation:-) As I understand it the main argument for the new message is to make delete operations explicit, so I'm just applying that argument to the new message - that it ought to contain an explicit indicator for delete-all rather than depend on an "empty" or missing credential. Also, I don't agree that accidental inclusion is as likely as accidental omission - if some substructure pointer is nulled due to a bug (much more likely than accidentally adding an xml attribute to real xml codec data structures I'd argue) then the delete-all will happen. But, I admit I'm partly guessing here, so if someone who's familiar with xml codecs could speak up, we'd be on firmer ground. Stephen. > I > can't see that it is to avoid "unintended" delete-all, since the client > could just as well happen to send an explicit delete-all as sending an > implicit one - it all happens under the hood anyway, and I would assume > that a well-behaving client would require the user to do something > explicit in order to delete all his/her credentials. > > -- Magnus > > On Mon, 3 Feb 2003, Stephen Farrell wrote: > > > > > > > If we adopt the new message, that'd make more sense. > > > > What about making delete-all explicit? I assume you'd agree with > > that too? How'd you want that done? > > > > Stephen. > > > > "Richards, Gareth" wrote: > > > > > > Stephen, > > > > > > > > > > > Meanwhile, if we did make this change, where'd be the text that > > > > tells the server what to do when it gets an UploadRequest > > > > containing zero credentials? > > > > > > I would think that if we do have a DeleteRequest then there is no need to > > > allow an empty UploadRequest and so the start of section 2.2.1 could be: > > > > > > 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 MUST > > > contain one Credential. > > > > > > The schema could then be: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Stephen. > > > > > > > > "Richards, Gareth" wrote: > > > > > > > > > > Stephen, > > > > > > > > > > Sorry for the delay in getting back to you on this. > > > > > > > > > > A simple form of DELETE request could be something like this: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > maxOccurs="1"/> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 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 > > > > > > > > > > > > > > -- > > > > ____________________________________________________________ > > > > 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 > > > > > > > > -- > > ____________________________________________________________ > > 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 > > -- ____________________________________________________________ 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 From owner-ietf-sacred@mail.imc.org Wed Feb 5 02:57:21 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 CAA13635 for ; Wed, 5 Feb 2003 02:57:21 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h157vwe26263 for ietf-sacred-bks; Tue, 4 Feb 2003 23:57:58 -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 h157vud26249 for ; Tue, 4 Feb 2003 23:57:56 -0800 (PST) Received: from no.name.available by tholian.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 5 Feb 2003 07:57:56 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 CAA28625 for ; Wed, 5 Feb 2003 02:57:55 -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 h157sde04682 for ; Wed, 5 Feb 2003 02:54:39 -0500 (EST) Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <1HMRJGB8>; Wed, 5 Feb 2003 02:57:51 -0500 Received: from dhcp-pool02.local.aus.rsa.com (MNYSTROM-LAP [10.177.1.236]) by exrsa01.rsa.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1JNKTA6P; Tue, 4 Feb 2003 23:57:48 -0800 From: "Nystrom, Magnus" Reply-To: "Nystrom, Magnus" To: ietf-sacred@imc.org Date: Wed, 5 Feb 2003 17:57:26 +1000 (E. Australia Standard Time) Subject: Re: Credential DELETE Operation In-Reply-To: <3E3FA5A2.87658DF@baltimore.ie> Message-ID: References: <418A63CAEBF2D4118A1A00508BB1A0B802BB1052@exuk01> <3E3E9307.FDD1D996@baltimore.ie> <3E3FA5A2.87658DF@baltimore.ie> X-X-Sender: mnystrom@[10.81.217.7] 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: On Tue, 4 Feb 2003, Stephen Farrell wrote: > Magnus, > > > For the explicit "delete-all", could you explain why you suggest this? > > Merely applying blind logic to the situation:-) As I understand it the > main argument for the new message is to make delete operations explicit, > so I'm just applying that argument to the new message - that it ought > to contain an explicit indicator for delete-all rather than depend on > an "empty" or missing credential. But then you will have to define what's meant with a message containing an identifier but also the "delete-all" attribute. I think it is cleaner with a situation where the non-existence of an identifier is treated as delete-all. But it is not the most important issue for me, the inclusion of the DELETE operation is much more so. > Also, I don't agree that accidental inclusion is as likely as > accidental omission - if some substructure pointer is nulled due > to a bug (much more likely than accidentally adding an xml attribute > to real xml codec data structures I'd argue) then the delete-all will > happen. But, I admit I'm partly guessing here, so if someone who's > familiar with xml codecs could speak up, we'd be on firmer ground. I'd say this is as likely as an ASN.1 encoder happening to receive a NULL pointer to a string and then happily encoding it as an empty string and my opinion is that it would be a serious problem - for that vendor, and something which should have been caught during QA, but not for the protocol. -- Magnus > > I > > can't see that it is to avoid "unintended" delete-all, since the client > > could just as well happen to send an explicit delete-all as sending an > > implicit one - it all happens under the hood anyway, and I would assume > > that a well-behaving client would require the user to do something > > explicit in order to delete all his/her credentials. > > > > -- Magnus > > > > On Mon, 3 Feb 2003, Stephen Farrell wrote: > > > > > > > > > > > If we adopt the new message, that'd make more sense. > > > > > > What about making delete-all explicit? I assume you'd agree with > > > that too? How'd you want that done? > > > > > > Stephen. > > > > > > "Richards, Gareth" wrote: > > > > > > > > Stephen, > > > > > > > > > > > > > > Meanwhile, if we did make this change, where'd be the text that > > > > > tells the server what to do when it gets an UploadRequest > > > > > containing zero credentials? > > > > > > > > I would think that if we do have a DeleteRequest then there is no need to > > > > allow an empty UploadRequest and so the start of section 2.2.1 could be: > > > > > > > > 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 MUST > > > > contain one Credential. > > > > > > > > The schema could then be: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Stephen. > > > > > > > > > > "Richards, Gareth" wrote: > > > > > > > > > > > > Stephen, > > > > > > > > > > > > Sorry for the delay in getting back to you on this. > > > > > > > > > > > > A simple form of DELETE request could be something like this: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > maxOccurs="1"/> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 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 > > > > > > > > > > > > > > > > > -- > > > > > ____________________________________________________________ > > > > > 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 > > > > > > > > > > > -- > > > ____________________________________________________________ > > > 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 > > > > > -- > ____________________________________________________________ > 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 > From owner-ietf-sacred@mail.imc.org Wed Feb 5 10:01:28 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 KAA27448 for ; Wed, 5 Feb 2003 10:01:27 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h15F17x13368 for ietf-sacred-bks; Wed, 5 Feb 2003 07:01:07 -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 h15F15d13363 for ; Wed, 5 Feb 2003 07:01:06 -0800 (PST) Received: from no.name.available by tholian.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 5 Feb 2003 15:01:07 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 KAA28380; Wed, 5 Feb 2003 10:01:06 -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 h15EvWF10053; Wed, 5 Feb 2003 09:57:32 -0500 (EST) Received: by exuk01 with Internet Mail Service (5.5.2653.19) id ; Wed, 5 Feb 2003 15:05:33 -0000 Message-ID: <418A63CAEBF2D4118A1A00508BB1A0B802BB1063@exuk01> From: "Richards, Gareth" To: "'stephen.farrell@baltimore.ie'" Cc: ietf-sacred@imc.org Subject: RE: Credential DELETE Operation Date: Wed, 5 Feb 2003 15:05:32 -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, It is not clear to me how we could make an explicit delete-all clean and unambiguous. As mentioned by Dale earlier, the DeleteRequest could have a "DeleteAll" attribute empty and the DeleteAll attribute to be used in this type of request. For example: However, as mentioned by Magnus, this schema allows for the DeleteAll to be present if the CredentialSelector is present which doesn't really make sense if the attribute is true. I don't know how to define the schema to not allow this. Does anyone know of a way? Another possibility mentioned was to have a reserved CredentialSelector value which I think would introduce extra error conditions that would have to be described for other PDUs. For example, this name cannot be used in an upload request. Do we actually need a delete-all? If we are concerned about accidental deletion of all a user's credentials then we could require that they are all explicitly deleted by name. Just a thought. > > > If we adopt the new message, that'd make more sense. > > What about making delete-all explicit? I assume you'd agree with > that too? How'd you want that done? > > Stephen. > > "Richards, Gareth" wrote: > > > > Stephen, > > > > > > > > Meanwhile, if we did make this change, where'd be the text that > > > tells the server what to do when it gets an UploadRequest > > > containing zero credentials? > > > > I would think that if we do have a DeleteRequest then there > is no need to > > allow an empty UploadRequest and so the start of section > 2.2.1 could be: > > > > 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 MUST > > contain one Credential. > > > > The schema could then be: > > > > > > > > > > > > > > > > > > > > > > > > Stephen. > > > > > > "Richards, Gareth" wrote: > > > > > > > > Stephen, > > > > > > > > Sorry for the delay in getting back to you on this. > > > > > > > > A simple form of DELETE request could be something like this: > > > > > > > > > > > > > > > > > > > > > > > > > > maxOccurs="1"/> > > > > > > > > > > > > > > > > > > > > > > > > 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 > > > > > > > > > > > -- > > > ____________________________________________________________ > > > 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 > > > > > -- > ____________________________________________________________ > 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 > From owner-ietf-sacred@mail.imc.org Fri Feb 7 09:34:33 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 JAA12465 for ; Fri, 7 Feb 2003 09:34:32 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h17EXjr04143 for ietf-sacred-bks; Fri, 7 Feb 2003 06:33:45 -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 h17EXid04139 for ; Fri, 7 Feb 2003 06:33:44 -0800 (PST) Received: from no.name.available by tholian.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 7 Feb 2003 14:33:45 UT Received: from exuk01.securid.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id JAA20616; Fri, 7 Feb 2003 09:33:41 -0500 (EST) Received: by exuk01 with Internet Mail Service (5.5.2653.19) id ; Fri, 7 Feb 2003 14:38:40 -0000 Message-ID: <418A63CAEBF2D4118A1A00508BB1A0B802BB1081@exuk01> From: "Richards, Gareth" To: "'stephen.farrell@baltimore.ie'" Cc: ietf-sacred@imc.org Subject: RE: Credential DELETE Operation Date: Fri, 7 Feb 2003 14:38:39 -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, Maybe a DeleteRequest with an explicit delete-all could be like this. What I have tried to do is to make it so that a delete-all is not syntactically legal if it contains a CredentialSelector. A delete-all would be a DeleteRequest with an element and an optional ProcessInfo. A normal delete would be a DeleteRequest with a CredentialSelector and optional LastModified and ProcessInfo elements. A new section could then be as follows. 2.2.3 Credential Delete This operation REQUIRES mutual authentication. The purpose of this operation is to allow the client to delete one or all credentials associated with the account. The client sends an DeleteRequest message to the server which can contain either a CredentialSelector or an All element. If the DeleteRequest contains an All element then the all the credentials associated with that account are deleted. If the DeleteRequest contains a CredentialSelector then the request MAY include a LastModified value. 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. If no "matching" credential exists, the server returns an error. The server responds to this request with an error or acknowledgement message. > > > If we adopt the new message, that'd make more sense. > > What about making delete-all explicit? I assume you'd agree with > that too? How'd you want that done? > > Stephen. > > "Richards, Gareth" wrote: > > > > Stephen, > > > > > > > > Meanwhile, if we did make this change, where'd be the text that > > > tells the server what to do when it gets an UploadRequest > > > containing zero credentials? > > > > I would think that if we do have a DeleteRequest then there > is no need to > > allow an empty UploadRequest and so the start of section > 2.2.1 could be: > > > > 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 MUST > > contain one Credential. > > > > The schema could then be: > > > > > > > > > > > > > > > > > > > > > > > > Stephen. > > > > > > "Richards, Gareth" wrote: > > > > > > > > Stephen, > > > > > > > > Sorry for the delay in getting back to you on this. > > > > > > > > A simple form of DELETE request could be something like this: > > > > > > > > > > > > > > > > > > > > > > > > > > maxOccurs="1"/> > > > > > > > > > > > > > > > > > > > > > > > > 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 > > > > > > > > > > > -- > > > ____________________________________________________________ > > > 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 > > > > > -- > ____________________________________________________________ > 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 >