Subject: enrollment/mgt operations

From: Stephen Farrell <[email-masked]>
Date: Fri, 27 Oct 2000 15:28:46 +0100

Hi All,

I'm looking through the comments we got on the requirements and
would like to get some opinions about how much detail to include
(in the requirments document) about management operations.

Right now, there's just a generic requirement that the
protocols must support mgt operations. Self-enrollment was
mentioned on the list and should at least get a mention too.

I guess the overall list of operations might be something
like:

GET      for downloads from a CS
PUT      to update/change a credential or direct transfer one
ENROLL   could be a special case of PUT?
DELETE   to zap a credential (carefully:-)

So, questions:

- Should the requirements document specify these separately, 
  each with associated MUSTs etc?
- If yes, then what other management operations might there be? 
  (e.g. do we need an interoperable form of DISABLE/ENABLE to 
  temporarily make credentials unavailable, MODIFY to change
  an existing credential...)
- Does all this just apply to the credential server case, or
  also for direct transfers?

Regards,
Stephen.

BTW: Dale and Magnus have taken on drafting a framework document
(thanks guys:-) so we should have one to discuss in San Diego if
they manage to make the cutoff.

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) +353 1 647 7406
61 Fitzwilliam Lane,                    fax: +353 1 647 7499
Dublin 2.                mailto:[email-masked]
Ireland                             http://www.baltimore.com

---

From: Carlos Sotomayor <[email-masked]>
Date: Mon, 30 Oct 2000 10:02:27 +1100

I think there should be some clarification of the management issues. Some
queries I have are ...

Are there plans to provide delegated credential access. An example could be
that a manager could be given access to the team members credentials or a
secretary could read and decrypt mail for the person they work for. Also
there should be the ability to make an entity a retrieval authority such as
a system admin or high ranking company employee.

Also what about scenarios of revoking access to credentials for an entity
but still allow the credential to be retrieved by another entity or
authority. This could happen in a company when an employee leaves the
company but their correspondence still needs to be accessible by an existing
member of the company.

Registering a new entity onto the system may warrant its own function. Many
things could be configured at this point such as authentication method for
that entity and also it provides a point at which an admin person can
actually reject or allow an entity access to the system. There might be
other situations where there already exists a compant entity registration
database which is to be reused so the user registration will not
neccessarily happen on the first credential upload.

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]]
Sent: Saturday, 28 October 2000 0:29
To: ietf-sacred
Subject: enrollment/mgt operations

Hi All,

So, questions:

Regards,
Stephen.