Subject: [POSH] Delegation duration

From: Michael Procter <[email-masked]>
Date: Tue, 17 Sep 2013 13:46:00 +0100

Thanks for issuing -01, which addresses some of my questions.  I'm still
concerned about one area though.  To repeat from an earlier email:

> In section [7], you state that ideally, caching of the certificate
> obtained via POSH should be based on the expiration time of the
> certificate.  I think this might be a little too trusting, as it ties
> delegation validity to certificate expiry.  If I trust
> hosting.example.net to host my service today, that doesn't mean I will
> continue to trust them until their certificate expires.  HTTP
> cache-control headers might be a useful way of indicating a short term
> trust though.

I think it would be useful to consider adding a "validity" field somewhere,
indicating either a duration (this delegation valid for 24 hours) or an
expiry (this delegation valid until 17th Sep 2013).  Whether this is done
via cache-control headers, or a new field in the jwk, or some other
mechanism is less important to me, so long as there is some way of
indicating how soon the delegation may be revoked.

Regards,

Michael

---

From: "Olle E. Johansson" <[email-masked]>
Date: Tue, 17 Sep 2013 17:04:15 +0200

17 sep 2013 kl. 14:46 skrev Michael Procter <[email-masked]>:

> Thanks for issuing -01, which addresses some of my questions.  I'm still concerned about one area though.  To repeat from an earlier email:
> 
> I think it would be useful to consider adding a "validity" field somewhere, indicating either a duration (this delegation valid for 24 hours) or an expiry (this delegation valid until 17th Sep 2013).  Whether this is done via cache-control headers, or a new field in the jwk, or some other mechanism is less important to me, so long as there is some way of indicating how soon the delegation may be revoked.
> 
Caching to expiry time is not acceptable. I do agree that we need to have a header to define a decent caching time.

/O

---

From: "Matt Miller (mamille2)" <[email-masked]>
Date: Tue, 17 Sep 2013 16:34:49 +0000

> Caching to expiry time is not acceptable. I do agree that we need to have a header to define a decent caching time.

I can see value in a duration/TTL, as long as that duration is short (IMO, at most 24 hours).  It's fairly easy to maintain in deployment, and provides the practical benefit we're looking for.

I also think an absolute expires is a bad idea. Given that I think we want very short durations, an absolute expires time means the document needs to be continuously updated, which increases the burden on deployments.

I will confer with my co-author on this, but I think putting something in the POSH document is the most pragmatic approach.

- m&m

Matt Miller < [email-masked] >
Cisco Systems, Inc.

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 17 Sep 2013 15:25:25 -0600

On 9/17/13 10:34 AM, Matt Miller (mamille2) wrote:
>>> Thanks for issuing -01, which addresses some of my questions. 
>>> I'm still concerned about one area though.  To repeat from an 
>>> earlier email:
>>> 
>>>> In section [7], you state that ideally, caching of the 
>>>> certificate obtained via POSH should be based on the
>>>> expiration time of the certificate.  I think this might be a
>>>> little too trusting, as it ties delegation validity to
>>>> certificate expiry. If I trust hosting.example.net to host my
>>>> service today, that doesn't mean I will continue to trust
>>>> them until their certificate expires.  HTTP cache-control
>>>> headers might be a useful way of indicating a short term
>>>> trust though.
>>> 
>>> I think it would be useful to consider adding a "validity"
>>> field somewhere, indicating either a duration (this delegation
>>> valid for 24 hours) or an expiry (this delegation valid until
>>> 17th Sep 2013).  Whether this is done via cache-control
>>> headers, or a new field in the jwk, or some other mechanism is
>>> less important to me, so long as there is some way of
>> Caching to expiry time is not acceptable. I do agree that we
>> need to have a header to define a decent caching time.
>> 
> 
> I can see value in a duration/TTL, as long as that duration is
> short (IMO, at most 24 hours).  It's fairly easy to maintain in
> deployment, and provides the practical benefit we're looking for.
> 
> I also think an absolute expires is a bad idea. Given that I think
> we want very short durations, an absolute expires time means the 
> document needs to be continuously updated, which increases the
> burden on deployments.

Agreed on the foregoing.

> I will confer with my co-author on this, but I think putting 
> something in the POSH document is the most pragmatic approach.

Yes, as long as when you say "the POSH document" you mean the hosted
JSON file, not the Internet-Draft. :-)

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/