Subject: Additional operations

From: Tom Jordan <[email-masked]>
Date: Tue, 27 Mar 2001 09:31:03 -0600 (CST)

Folks,

In addition to the specified operations (GET-PUT-DELETE), I'd invite
discussion on the need for operations to be applied by an administrative
user. I'd propose two new operations - LOCK and UNLOCK that would
respectively limit or allow a user to retrieve credentials without the
need to destroy the credentials themselves.

Granted that this implies maintaining some state information regarding the
opaque credentials themselves, but perhaps there's some value to it.

	--Tom

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 27 Mar 2001 17:11:34 +0100

Hi Tom,

That'd extend the scope of what we're doing to include administrative
functionality in the protocol. To date, I don't think we've envisaged
that being the case (since there are a few different, probably all 
fairly complex administrative schemes you could envisage). So my take
would be that admin operations would be for later, if at all, since
they don't affect interop that much (I'd assume each credential server
implementation would have its own admin tools, and they don't really
need to interop in the first instance).

Or maybe you didn't mean LOCK/UNLOCK as administrative?

Stephen.

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) +353 1 881 6716
39 Parkgate Street,                     fax: +353 1 881 7000
Dublin 8.                mailto:[email-masked]
Ireland                             http://www.baltimore.com

---

From: Michael R Gettes <[email-masked]>
Date: Tue, 27 Mar 2001 13:28:58 -0500

> Or maybe you didn't mean LOCK/UNLOCK as administrative?

I think there needs to be some consideration of what possible
administrative abilities might impact the protocol.  For example,
a locked cred store might need to give back an appropriately
descriptive error.  Beyond that, I tend to agree that this is out
of bounds, for now.

/mrg

---

From: Tom Jordan <[email-masked]>
Date: Tue, 27 Mar 2001 12:04:43 -0600 (CST)

I did mean the LOCK/UNLOCK function to be administrative. If
administrative functions would be separate from the SACRED protocol
itself, then they would not belong there.

Are there any plans for an administrative commandset that would work
across implementations? If the administrative interfaces for SACRED are
vendor dependent, it will be hard for administrators to manage credentials
across different servers/devices.

If I have to touch several  different interfaces to lock a user's
credentials due to the fact that the admin operations are vendor dependent, it seems as
though the utility of the protocol is somewhat diminished.

	--Tom

---

From: Dale Gustafson <[email-masked]>
Date: Tue, 27 Mar 2001 15:53:55 -0600

It may be necessary for the server to lock a particular user if someone is trying to login
in with incorrect password repeatedly.  We may want to describe that in the client/server
protocol if a standard capability is warranted.

Unlock/reset of the locked entity would still be an admin. function (server specific).

Regards,

--dg

---

From: Menno Pieters <[email-masked]>
Date: Tue, 27 Mar 2001 23:55:23 +0200

At 12:04 PM 3/27/01 -0600, Tom Jordan wrote:

><CUT>

>across different servers/devices.

While going through my mail archive I couldn't figure out whether it has 
been mentioned before, but I could imagine that a new credential to be 
stored on a credential server is accompanied by a descriptive header or 
attachment.
Such a header/attachment could include some administrative tags (lock, 
unlock, access-lists). Would it be a good idea to use [multipart/]mime 
format to pack a credential and accompanying information? If  I'm not 
mistaken, XML has also been mentioned before in such context.

Requirement F4 in the requirements draft states that the format MUST be 
opaque to the protocol, though not to processing in the protocol's peers. 
That would allow for extra information to be processed by a server, store 
or device, apart from the sacred protocol.

Regards,

Menno Pieters

>though the utility of the protocol is somewhat diminished.

<CUT>

+---------------------------------------+
|Menno Pieters                          |
|M&I/STELVIO bv                         |
|Zonnehof 41         |P.O. Box 2171     |
|3811 ND Amersfoort  |3800 CD Amersfoort|
|The Netherlands     |The Netherlands   |
|Phone:  +31(0)33-4697340               |
|Fax:    +31(0)33-4697341               |
+---------------------------------------+

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 28 Mar 2001 10:44:49 +0100

> descriptive error.  Beyond that, I tend to agree that this is out

Agreed. But the need for a sensible error indication "locked" (and 
probably others too) is a good catch.

Stephen.

---

From: Dale Gustafson <[email-masked]>
Date: Thu, 29 Mar 2001 09:51:44 -0600

Hi Menno,

Comments inline.

Best Regards,

Dale Gustafson

> mistaken, XML has also been mentioned before in such context.

I think lock/unlock has already been addressed.

We intend to use (HTML and) XML to encode the transactions exchanged between
client and server when http is used as the transport layer protocol.  The
Framework has been extended to allow support for additional transports such as
UDP, TCP, and BEEP.  Perhaps others could comment on the viability of using XML
over other transports.

I assume we will use a well defined (profiled) subset of the chosen credential
format's capabilities within SACRED.  Additional information exchanged between
clients (if needed) could be included within the credential (using PKCS-9
attributes inside a PKCS-12 credential, for example).  Additional info.
exchanged between client and server would most likely be included in the XML
encoded data (outside the credential).

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 29 Mar 2001 17:17:49 +0100

Hi Dale,
 
> client and server when http is used as the transport layer protocol.  

Well...two things:-

- I can't see how we'll be using HTML, though of course someone could
use HTML for forms, or generate HTML via XSLT somehow, but I don't think
any sacred protocol will use HTML

- XML should be usable for all transports, IMHO

Stephen.

---

From: Dale Gustafson <[email-masked]>
Date: Thu, 29 Mar 2001 12:23:48 -0600

Stephen,

> any sacred protocol will use HTML

Good point.  A server implementation might utilize HTML but the SACRED protocol
won't specify it's use.