Re: Time to live

[Stephen Farrell <stephen.farrell@xxxxxxxxxxxx>]

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:
> 
> 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.
> e
> ----- Original Message -----
> From: "Preetam Ramakrishna" <rpreetam@xxxxxxxxxx>
> To: <ietf-sacred@xxxxxxx>
> Sent: Monday, July 01, 2002 7:02 AM
> Subject: Time to live
> 
> >
> > 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

-- 
____________________________________________________________
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