Re: Time to live

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.


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