Subject: Missed Items

From: "Gareth Richards" <[email-masked]>
Date: Thu, 13 Dec 2001 17:38:06 -0000

The previous version of this mail was sent by mistake.

Due to the BEEP discussions, there was not time for a number of the
proposals contained within the I-D Delta to be raised.

1. Fingerprint
The I-D has a LastModified element in the credential format (section 3.2).
The proposal is that this be replaced with a fingerprint which would be
used as follows:

a) Returned by the server in the upload response (Framework section 5.1).
b) Optionally sent with the credentials in an upload request.  If it is not
included then the credentials are replaced unconditionally.
c) Optionally sent along with the credential selector in a download
request(Framework section 5.2).

The intention is that if the client has locally cached credentials then it
could use the fingerprint to conditionally download credentials if they are
newer.

2. Multiple Credentials.
The I-D has the credential selector as an optional argument in upload and
download requests (section 2.4).  If the selector was omitted then it is
used to select the default credentials.  We felt this could be potential
for confusing since the notion of a user's default credentials could vary
over time.  For example, if a user uploads credentials "cred1" and later
credentials "cred2" then "cred1" will be the default.  If "cred1" is later
deleted then presumably "cred2" would become the default and would be
downloaded with a null selector name.  There is similar possible confusion
during credential upload and delete when a user could inadvertently replace
the wrong credentials.

The proposal is that there will be no default credentials and that all
credentials must have a selector unique for that account.  The selector
would be required for upload requests and optional for download requests.
If omitted in a download request it would be interpreted as a request for
all the stored credentials.

3. Authorisation ID
Section 2.2 of the ID requires that the BEEP session MUST set the
authorisation identity to the same value as the authentication identity.
It is not clear why this restriction is required and we therefore proposed
that if an authorisation ID was specified during the SASL negotiation then
it would be used to identify the account used.  (We could think of no
particularly compelling reason for doing this, we just couldn't think of
any reason why it shouldn't work that way.)

4.  Credential Format
The credential format (section 3.2) contains a KeyID containing an XKMS
related URI.  This seemed to be putting XKMS specifics in the SACRED PDU
which should ideally treat the credentials as an opaque blob.

5. ProcessInfo
Since xbulk:ProcessInfo is in the UploadRequest, it does not seem to be
required in the CredentialType (section 3.2).  It would be possible to pass
the required information as part of the basic request.

6. TimeToLive and ClientInfo
The same credential element is used for credential upload and download.
This type contains TimeToLive and ClientInfo elements that contain
information from the server to the client.  Since there is no reason for
the client to return this information we propose removing them from the
upload request.

7. Error Status.
This issue could be seen as BEEP related but whichever transport or
authentication system is used there will need to be a way of reporting
status information back to the SACRED client.  We therefore propose that
each response message should contain a status attribute and optional
human-readable descriptive text.

Gareth Richards

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 13 Dec 2001 18:26:54 +0000

This looks fine to me.

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: Stephen Farrell <[email-masked]>
Date: Thu, 13 Dec 2001 18:29:38 +0000

I think this'll change, depending on how xkms evolves, but I
agree that we shouldn't put xkms specifics in sacred
pdus, except maybe via some extensibility mechanism or within
the credential itself.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 13 Dec 2001 18:30:55 +0000

I think this is possibly ok, but I want to think about it for
a bit (I'm a bit wary of (c) below - can't see why a client
would bother checking?)

Stephen.

---

From: "Gareth Richards" <[email-masked]>
Date: Fri, 14 Dec 2001 12:54:12 -0000

The reason the client would check is to reduce the number of credential
downloads. If the fingerprint isn't used then the credentials would have to
be downloaded each time to ensure the current version is used.

The fingerprint could also be of use in detecting conflicts.  For example,
download to platform A, download to platform B, update from B, update from
A.  The server could detect a conflict on the second upload.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 19 Dec 2001 14:39:42 +0000

Gareth,

Ok, now I see what you're after. One issue - is there any reason
that the fingerprint should/should not be a digest? You're text
seemed (to me anyway) to imply that the fingerprint value would be
the hash of something, but I'd prefer that it be a time value, which
is more useful to human users. 

Also - I don't accept that we should try save bandwidth using this
trick. There's no rountrip savings involved since the check also
has to be secure. However, you're point about modifications is
valid - I'll add in a bit of text about that.

Stephen.

---

From: "Gareth Richards" <[email-masked]>
Date: Wed, 19 Dec 2001 15:00:48 -0000

I can see no reason why the fingerprint shouldn't be a last modified type
time value.

If the credentials are small then you are right that the saving will be
small since the client must go through the authentication process anyway.
It may be worth it if multiple sets of credentials are supported.

---

From: Dale Gustafson <[email-masked]>
Date: Wed, 19 Dec 2001 10:57:11 -0600

Gareth, Stephen,

For clarity, I'd like to see the terminology changed to "last modified" (or
something similar) rather than "version number" which is used interchangeably
with fingerprint, most recently.

One could envision corner cases where a fingerprint (hash of credential) might
have slightly more utility than a time/date value with respect to performing
conditional replace or delete operations via the SACRED Upload command.
However, it's difficult to conclude that fingerprint should replace
last-modified -- ease of use is more important here, IMO.

Best Regards,

Dale Gustafson