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
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" <rpreetam <at> novell.com>
To: <ietf-sacred <at> imc.org>
Sent: Monday, July 01, 2002 7:02 AM
Subject: Time to live
(Continue reading)
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. >(Continue reading)
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" <stephen.farrell <at> baltimore.ie>
To: "Al Arsenault" <awa1 <at> comcast.net>
Cc: "Preetam Ramakrishna" <rpreetam <at> novell.com>; <ietf-sacred <at> imc.org>
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
(Continue reading)
All, This message is to start a WG last call on the framework document. Since its summer (here) the last call will have a duration of one month, i.e. it ends on August 24th. The framrwork draft is at [1]. I hope to produce a new protocol document in the near future, which all going well, ought also be ready for last call. Stephen. [1] http://www.ietf.org/internet-drafts/draft-ietf-sacred-framework-04.txt -- -- ____________________________________________________________ Stephen Farrell Baltimore Technologies, tel: (direct line) +353 1 881 6716 39 Parkgate Street, fax: +353 1 881 7000 Dublin 8. mailto:stephen.farrell <at> baltimore.ie Ireland http://www.baltimore.com
RSS Feed1 | |
|---|---|
1 | |
3 | |
3 | |
2 | |
1 | |
4 | |
21 | |
1 | |
2 | |
1 | |
4 | |
3 | |
1 | |
1 | |
1 | |
3 | |
2 | |
1 | |
4 | |
3 | |
2 | |
9 | |
5 | |
18 | |
26 | |
16 | |
4 | |
7 | |
5 | |
6 | |
19 | |
22 | |
13 | |
21 | |
2 | |
105 | |
12 | |
22 | |
9 | |
14 | |
8 | |
11 | |
42 | |
38 | |
11 | |
19 | |
12 | |
17 | |
9 | |
25 | |
6 | |
59 |
