[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Credential DELETE Operation

To: ietf-sacred@xxxxxxx
Subject: Re: Credential DELETE Operation
From: "Nystrom, Magnus" <mnystrom@xxxxxxxxxxxxxxx>
Date: Wed, 5 Feb 2003 17:57:26 +1000 (E. Australia Standard Time)
In-reply-to: <>
List-archive: <http://www.imc.org/ietf-sacred/mail-archive/>
List-id: <ietf-sacred.imc.org>
List-unsubscribe: <mailto:ietf-sacred-request@imc.org?body=unsubscribe>
References: <> <> <> <>
Reply-to: "Nystrom, Magnus" <magnus@xxxxxxxxxxxxxxx>
Sender: owner-ietf-sacred@xxxxxxxxxxxx
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:
> > > >
> > > >         <!-- Upload request -->
> > > >         <element name="UploadRequest">
> > > >          <complexType>
> > > >           <sequence>
> > > >            <element name="Credential" type="sacred:CredentialType"/>
> > > >           </sequence>
> > > >          </complexType>
> > > >         </element>
> > > > >
> > > > > 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:
> > > > > >
> > > > > >         <element name="DeleteRequest">
> > > > > >          <complexType>
> > > > > >           <sequence minOccurs="0" maxOccurs="1">
> > > > > >             <element name="CredentialSelector" type="string"/>
> > > > > >             <element name="LastModified" type="dateTime"
> > > > > maxOccurs="1"/>
> > > > > >
> > > > > >           </sequence>
> > > > > >          </complexType>
> > > > > >         </element>
> > > > > >
> > > > > > 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@xxxxxxxxxxxx]
> > > > > > > Sent: 19 December 2002 12:16
> > > > > > > To: Richards, Gareth
> > > > > > > Cc: ietf-sacred@xxxxxxx
> > > > > > > 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@xxxxxxxxxxxx
> > > > > > > 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@xxxxxxxxxxxx
> > > > > 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@xxxxxxxxxxxx
> > > 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@xxxxxxxxxxxx
> Ireland                             http://www.baltimore.com
>
References:
- RE: Credential DELETE Operation
  - From: Richards, Gareth
- Re: Credential DELETE Operation
  - From: Stephen Farrell
- Re: Credential DELETE Operation
  - From: Nystrom, Magnus
- Re: Credential DELETE Operation
  - From: Stephen Farrell
Prev by Date: Re: Credential DELETE Operation
Next by Date: RE: Credential DELETE Operation
Previous by thread: Re: Credential DELETE Operation
Next by thread: RE: Credential DELETE Operation
Index(es):
- Date
- Thread