[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Time to live
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
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"
> 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.
> ----- 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
Baltimore Technologies, tel: (direct line) +353 1 881 6716
39 Parkgate Street, fax: +353 1 881 7000
Dublin 8. mailto:stephen.farrell@xxxxxxxxxxxx