Subject: Time to live

From: "Preetam Ramakrishna" <[email-masked]>
Date: Mon, 01 Jul 2002 05:02:20 -0600

Hi,

      The requirements RFC mentions a general requirement ( G11 ) of
time to live information associated with the downloaded credential by
the Credential Server. 
     The RFC also mentions that the credential format is opaque to the
protocol.

      Are there any scenarios that necessitated this requirement. 

Thanks,
Preetam.R

---

From: Al Arsenault <[email-masked]>
Date: Mon, 01 Jul 2002 10:55:18 -0400

The scenario for timing information (G11) is that credentials such as
private keys or trusted roots typically have validity periods, after which
they are no longer considered reliable.

For example, if a credential is a trusted root, but that root will expire in
two years, you could indicate that, so that the user downloading the
credential stops relying on that trusted root at the appropriate time.

Similarly, if the credential is a private key, and the certificate
associated with that private key expires in 90 days, the private key is no
longer useful after 90 days.  This would be indicated in the "time to live"
structure.

As far as the credential format being opaque to the protocol (requirement
F4), the reason for that is to drive a single framework to support any
credential format needed (e.g., PKCS12, PKCS15, PGP, ...).  That is, we
didn't want to wind up with a protocol specific to PKCS 15, and then another
protocol specific for PGP, and then..

        Al Arsenault
        Chief Security Architect
        Diversinet Corp.

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 01 Jul 2002 16:25:40 +0100

Al,

I seem to also remember people wanting to be able to setup a system
so that a particular credential might only be stored on a given 
client for a shortish period and the ttl setting indicates that. Two
things to note about that are:

- it'd mean ttl's in the minutes/hours range usually, rather than
  the months/years from your examples
- its recognized that this is up to the client to enforce and
  can't be a MUST for interop

Stephen.

Al Arsenault wrote:
> e

-- 
____________________________________________________________
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: Al Arsenault <[email-masked]>
Date: Mon, 01 Jul 2002 13:53:35 -0400

I agree with Stephen's comments here.  Yes, there are people who want to
support such a scenario; e.g., tell the client "download this credential and
delete it/don't use it after 24 hours".

Yes, the client would have to enforce this; there's no way SACRED could
enforce it (it's what Steve Kent and others refer to as a "local matter")
and thus it can't be a MUST.  We'll just make the field available.

            Al Arsenault