Re: Time to live

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

----- Original Message -----
From: "Stephen Farrell" <[email protected]>
To: "Al Arsenault" <[email protected]>
Cc: "Preetam Ramakrishna" <[email protected]>; <[email protected]>
Sent: Monday, July 01, 2002 11:25 AM
Subject: Re: Time to live


>
> 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" <[email protected]>
> > To: <[email protected]>
> > 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:[email protected]
> Ireland                             http://www.baltimore.com